Fun with NULL pointers, part 2

Posted Jul 22, 2009 4:54 UTC (Wed) by bojan (subscriber, #14302)
In reply to: Fun with NULL pointers, part 2 by spender
Parent article: Fun with NULL pointers, part 2

> You are correct though that the real problem is any invalid userland access in general.

Given the above and the fact that solutions to this type of bug exist (if I understand UDEREF correctly), why is the kernel not being patched so we don't see this ever again? Or am I being overly naive?

to post comments

Yes, you are overly naive...

Posted Jul 22, 2009 5:42 UTC (Wed) by khim (subscriber, #9252) [Link] (6 responses)

Given the above and the fact that solutions to this type of bug exist (if I understand UDEREF correctly), why is the kernel not being patched so we don't see this ever again? Or am I being overly naive?

The sad truth is that UDEREF is history now. The only architecture where it was useful slowly goes away: most architectures never had segments and Intel/Amd "lost" them recently: x86-64 does not have full segments in 64-bit mode... Segments only retained one attribute: base address, nothing else - good for TLS, not enough for UDEREF...

Yes, you are overly naive...

Posted Jul 22, 2009 6:56 UTC (Wed) by PaXTeam (guest, #24616) [Link] (5 responses)

Note that the fundamental problem in all this NULL deref misery is the lack of userland/kernel virtual address space separation. UDEREF/i386 simulates it by using the IA-32 segmentation logic, but there're certainly other ways to do the same, say address space ID tags in the TLB. Unfortunately AMD had butchered the segmentation logic without providing an alternative (it's not only about security, virtualization vendors weren't that happy either).

Yes, you are overly naive...

Posted Jul 22, 2009 8:02 UTC (Wed) by gmaxwell (guest, #30048) [Link] (2 responses)

How terrible for performance would it be to make all userspace accessible memory no-execute on kernel entrance? (or otherwise achieve the same result, like making it unreachable and then faulting it back in with NX-set).

Yes, you are overly naive...

Posted Jul 22, 2009 17:25 UTC (Wed) by dlang (guest, #313) [Link] (1 responses)

this would be _very_ expensive. changing the page tables is relativly expensive (especially if you have to do a lot of them)

Yes, you are overly naive...

Posted Jul 22, 2009 18:53 UTC (Wed) by PaXTeam (guest, #24616) [Link]

well, the actual page table manipulation would not be that expensive, with some tradeoffs you can reduce it to changing a few top-level page table entries and a single TLB flush, which would be a few hundred cycles or so.

however there's more cost to this: TLB repopulation which would inevitably occur after returning to userland. that is the real expense as we're talking about up to hundreds of TLB entries on modern CPU cores, each potentially missing in the data cache and incurring hundreds of cycles.

Yes, you are overly naive...

Posted Jul 22, 2009 11:13 UTC (Wed) by ajb (subscriber, #9694) [Link] (1 responses)

According to wikipedia newer cpus have an 'address space' tag which can be used to avoid flushing the TLB on VM switches. Could also be used for kernel vs user mode? It would require cooperating with the VM monitor though. (I wish VMs could be nested - it would be nice to be able to run untrusted code on EC2 without using QEMU. ).

Although that doesn't obviously help for the cases where the kernel needs to access user mode memory; one would still have to change the permissions to access it and then change them back.

NKX-bit

Posted Jul 22, 2009 23:37 UTC (Wed) by i3839 (guest, #31386) [Link]

Seems like the execute (and perhaps some other) memory permissions should be split up into user and kernel versions, that would solve this particular problem at least. That said, if they just got used to a separate no-execute bit, it may take a really long time before they introduce a no-kernel-execute bit (or ring0, whatever).