On 19 May 2015 at 13:46, Mel Gorman wrote: > On Thu, May 14, 2015 at 04:19:45PM +0200, Anisse Astier wrote: > > Hi, > > > > I'm trying revive an old debate here[1], though with a simpler approach than > > was previously tried. This patch series implements a new option to sanitize > > freed pages, a (very) small subset of what is done in PaX/grsecurity[3], > > inspired by a previous submission [4]. > > > > There are a few different uses that this can cover: > > - some cases of use-after-free could be detected (crashes), although this not > > as efficient as KAsan/kmemcheck > > They're not detected, they're hidden. this is a qualitative argument that cuts both ways. namely, you could say that uninitialized memory does *not* trigger any bad behaviour exactly because the previous content acts as valid data (say, a valid pointer) whereas a null dereference would pretty much always crash (both in userland and the kernel). not to mention that a kernel null deref is no longer an exploitable bug in many/most situations which can't be said of arbitrary uninitialized (read: potentially attacker controlled) values. that said, i always considered this aspect of page sanitization as a (potentially useful) side effect, not the design goal. > > - finally, it can reduce infoleaks, although this is hard to measure. > > > > It obscures them. i don't understand, what is being obscured exactly? maybe the term 'infoleaks' is ambiguous, in case of page sanitization it refers to the reduction of data lifetime (mostly userland anonymous memory, as per the original design). if you were thinking of kernel->userland kind of leaks then i'd say that page sanitization has little effect there because all the bugs i can think of were not leaking from freed memory (where sanitization would have prevented the leak). -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>