[grsec] KERNEXEC^Vmware?

[pageexec at freemail.hu]

On 12 Jan 2006 at 11:38, Angelo Dell'Aera wrote:
> 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).

as i explained in the previous mail, there's no need to work it
around this way, vmware can be simply patched to do its job.

> 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".

you don't need to, you could also just decode the faulting insn
and emulate it yourself in the page fault handler (like EMUTRAMP
does it for userland nested function calls).

> 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. 

when people resort to this they normally use single stepping to
execute one insn in the target then regain control (and disable
interrupts if they want 'atomicity', modulo NMI).

> 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. 

the open/close kernel calls (actually, macros that are inlined and
not 'exported') are my 'official' way to give write access to
otherwise read-only kernel memory so using them is the right way ;-).

and because they always come in pair, you can be sure that the kernel
never remains open (there is more to this, such as protecting against
control flow hijacking attacks, but think of the current code as a
testing ground for certain build blocks of a bigger scheme that has
yet to be fully finished).