Virtual Machines and Memory Protections
Posted Nov 23, 2006 19:20 UTC (Thu) by bluefoxicy
In reply to: Virtual Machines and Memory Protections
Parent article: Virtual Machines and Memory Protections
> When it's actually calling mmap or mprotect, the process context is present, and the kernel can see if it actually has the permission before it makes the change
Consider that the kernel doesn't know who called mmap() or mprotect() though. mmap() goes into mmap@@GLIBC, which goes into syscall@@GLIBC, which enters the kernel at the syscall entry point plus the offset for mmap(). Same with mprotect().
The kernel isn't tracking code call paths (this is difficult, would be very slow, and can be spoofed); it's the entire process that's allowed to do it. If you say the JIT is allowed to call mprotect(PROT_WRITE|PROT_EXECUTE), and the JIT links with libxml2, then a bug in libxml2 will allow an attacker to mprotect(PROT_WRITE|PROT_EXECUTE) ONLY in the JIT process and not in any other program using libxml2.
I'm trying to think of a way to contextually control calls, but right now there's no mechanism and nothing I can prove secure. I will think about it.
to post comments)