On Fri, 18 Sep 2009, Pieter de Boer wrote:
Julian wrote:
The assumption is that the userland and kernel share a memory map.
While we do implement it this way, it is not necessarily needed.
We do it for performance reasons (each user memory map includes an
identical top section that is the kernel space, so that we do not need
to switch memory page arenas (change CR3) when entering the kernel.
However it might be possible to not do this, and in fact on some
hardware it is mandatory to not do this).
It would require a page table arena switch with each syscall which
would require flushing the TLBs which would be expensive..
Hmm I guess I've talked myself out of this as a solution.. :-)
So, to be able to run VM86 mode or Wine we could make the NULL mapping
protection a configurable kernel option, (defaulting to 'on'?), which
doscmd/wine users could turn off.
Does VM86 mode really require or use mapping to kernel address 0? I think
it doesn't and shouldn't, since VM86 mode gets a special %cs which can
have a nonzero base address. Hmm, the user %cs is always different from
the kernel %cs, so I think it can alway have a nonzero base, but then
user addresses would be different from kernel address, which would require
large changes and small extra runtime to convert the addresses. VM86
mode would hopefully require only small or null changes since it is already
weird.
A nicer way would be to be able to map
0x0 in userland while having the kernel use its own 0x0 mapping.
Possibly there is a way to do that without making context switches very
expensive? Partial TLB flushes??
Not just context switches, but all kernel entries and exits are relevant.
I think the cost of switching the map would be small if you only do
it when necessary (on every kernel entry/exit from/to a user context
that has pages mapped near address 0). Most switches should be null
since most processes shouldn't do that. This can be optimized a bit
more by delaying the switch back to the unsafe user map until userland
actually accesses a low address.
Bruce
_______________________________________________
[email protected] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "[email protected]"
