Hello!
> This modified version is now in CVS, please check it out whether it
> works for you.
Yes, it works.
> > Attached patch fixes this and
> > buffer overflows in user (we'll need to make user suid in future
> > anyway, if we want ordinar users to access it, ain't we?)
> Actually, I think we should try to avoid that. I know that VMWare
Then we need to have more control under user. Originally I thout that
I can run several "user" processes and consume multiple amounts
of kernel memory, and make a nice DOS, but I found that
we have all allocated addresses in one static array, and when I
started second instance of 'user' - BOOM! Reboot...
Shouldn't we allow multiple execution of guests?
> forces the user mode app to run as root, because they cannot allow
> non-root access to their device node. This is because they export
> extremely dangerous functionality via ioctl(); in fact, one of their
> ioctl()s basically says: here's a function pointer, please call this
> function while executing at ring-0 :-)
Wow! I think I need to look closer at these VMWare modules... ;)
> The point of this appears to be that they want to keep most of their
> ring-0 code out of the kernel module (presumably so that they don't need
> to make the source public). As we don't need to do that (we simply have
> the complete ring-0 part of the monitor inside the kernel module), we
> don't need to export dangerous functionality. This implies that we
> should be able to have enough safeguards at the user/kernel boundary
> that *no* action of the user mode can endanger system stability or
> compromise security (of the host system, that is. Of course you can
> corrupt the *guest*, but I don't think that matters ...).
> Therefore, we should be able to allow everyone to access the device
> node, and hence there's no need for the user mode app to run suid root ...
Then we need some way to restrict memory usage by guests of one user...
> > Also I suggest to add this piece to kernel/include/host-linux.c:
> > #if LINUX_VERSION_CODE >= VERSION_CODE(2,3,26)
> > # define vm_offset vm_pgoff
> > #endif
> Ah, that is not enough. The point of the name change is that the
> *contents* changed, too. The new vm_pgoff now contains a *page* number,
Oops... missed that, and guess what?
mordor:~$ uname -a
Linux mordor 2.3.29 #3 Fri Nov 26 21:07:41 EET 1999 i586 unknown
mordor:~$ /sbin/lsmod | head -2
Module Size Used by
freemware 22616 0 (unused)
And guest runs just fine... (need to comment out proc_[un]register, thou)
> not a byte offset, AFAIK. This means that the use of the variable needs
> to change too (basically, you'd need to replace vm_offset by
> (vm_pgoff * PAGE_SIZE) or something like that) ...
patch-2.3.26 contains bunch of such lines (and similar):
- addr += vma->vm_offset;
+ off = vma->vm_pgoff << PAGE_SHIFT;
+ addr += off;
So, why we can't do the same?
> There will be more problems in any case; this whole new BIGMEM/HIGHMEM
> stuff completely breaks our idea of what the page tables look like ;-)
And are you sure that anybody with BIGMEM will ever be interested to
run some other OSes code? And we always can say that "BIGMEM/HIGHMEM
is *NOT* supported", in case it actually will not work.
Bye,
Oleg
PS: from ChangeLog:
- "Oleg Drokin" <[EMAIL PROTECTED]>:
Please change [EMAIL PROTECTED] to [EMAIL PROTECTED]
I just used former address due to lack of access to my main server at Uni
for now.
(Why all these servers always crash at Friday evening, so nobody
can fix them till monday morning? :-\)
