[grsec] KERNEXEC^Vmware?

[Angelo Dell'Aera]

On Thu, 12 Jan 2006 02:15:00 +0100
pageexec at freemail.hu wrote:

> as for fixing it, you (or vmware, if they cared) would have to add
> pax_open_kernel/pax_close_kernel calls around all the code that
> attempts to modify read-only memory. short of source code, one can
> resort to binary patching, but that'll be a bit of black magic ;-).

Yesterday night I took a closer look at the sources and I found the same
things you said. :) 

As for fixing it, I was thinking a workaround could be to add few lines
of code in do_page_fault (maybe through using something such as
CONFIG_VMWARE_KERNEXEC_WORKAROUND or something like
that that could be enabled at compile time just if the user needs
vmware).

In fact we know vmware-mon needs to modify the TSS busy bit. So we
know anything. We know the address it's trying to modify and who is
trying to do it. So we could think about another fixup function which
looks at the address causing the page fault and at the process and in
such case allows the vmware-mon operation thus allowing vmware to
properly work.

The problem to face here is that if the exception is fixed this way we
are forced to go out from do_page_fault in such a way to allow
vmware-mon to take again the CPU and do its own "dirty work". This means
that if we want to re-enable KERNEXEC just after vmware-mon has done,
do_fage_fault needs to schedule something which we'll do it and this is
absolutely not a beautiful thing I think since there's no guarantee
about when it'll be executed thus leaving the KERNEXEC disabled for a
not predictable amount of time.

Moreover I don't like too much the idea of creating pax_open_kernel and
pax_close_kernel thus allowing KERNEXEC enabling/disabling because it
gives the possibility to completely disable the feature at run-time
without reenabling it. IMHO the kernel has to handle anything without
providing any kind of potentially malicious exported symbol. 


Regards,

-- 

Angelo Dell'Aera 'buffer' 
Antifork Research, Inc.	  	http://buffer.antifork.org
Metro Olografix

PGP information in e-mail header


-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://grsecurity.net/pipermail/grsecurity/attachments/20060112/b1129286/attachment.pgp