Writing Kernel Exploits [pdf](ugcs.net)
ugcs.net
Writing Kernel Exploits [pdf]
http://ugcs.net/~keegan/talks/kernel-exploit/talk.pdf
1 comments
Really? That sounds like it'd be very inefficient when performing context-switching heavy tasks. Does OSX just take the cache penalty or does it somehow compensate with carefully written syscalls?
[deleted]
[deleted]
Is that still true with Mountain Lion? It is 64 bit only, so giving up say half the address space for kernel memory should not have any practical disadvantage.
Also, is that true on iOS? I would think that the better performance of say a 2G-2G split would be more than worth it there, as the hardware has, at best, 1GB or so.
Also, is that true on iOS? I would think that the better performance of say a 2G-2G split would be more than worth it there, as the hardware has, at best, 1GB or so.
That's interesting. What are the reasons some kernels choose to share the address space, while others don't (and/or how is it even possible to avoid that?)
Mostly performance.
Sharing the address space avoids switching the address space mappings (page tables, etc) and flushing the TLB every time the kernel runs (e.g. on syscalls).
[deleted]
Does that mean the TLB is flushed with every syscall?
The Mac OS X/iOS kernel (xnu) doesn't share the address space with the user process, so many of those techniques (I haven't read the whole paper) do not apply.