Re: [patch 0/5] Support for sanitization flag in low-level page allocator

[Alan Cox <alan@lxorguk.ukuu.org.uk>]

> Right, so the whole point is to minimize the impact of actual bugs,
> right? So why not focus on fixing those actual bugs? Can we create tools
> to help us find such bugs faster? We use sparse for a lot of static
> checking, we create things like lockdep and kmemcheck to dynamically
> find trouble.
> 
> Can we instead of working around a problem, fix the actual problem?

Why do cars have crashworthiness and seatbelts ? Why not fix the actual
problem (driving errors) ? I mean lets face it they make the vehicle
heavier, less fuel efficient, less fun and more annoying to use.

> Wiping everything because we're too 'lazy' to figure out what really
> matters otoh seems silly.

It isn't about being lazy. A program cannot deduce what is or is not
sensitive. Consider the simple case of writing a highly confidential
document, encrypting it with GPG and deleting (secure deleting even) the
document. 

The chances are you write it in openoffice, which has no idea
it is secure, copies of bits of it end up mashed around by the glibc
allocator and on the stack in pages that then get recycled into kernel
space on page frees. We then clear them later as they go back to user
space - assuming they don't leak or get copied.

For most of us that probabilities of that data not leaking are fine, but
not for all.

The kernel has no idea what data it touches may be confidential and the
user space often doesn't either. Even if it did in a highly secure
environment you want to enumerate what is safe not try and label what is
not.

Think about it this way - is it better to have a root password you guard
carefully, or to give everyone the root password except the list of bad
guys you maintain ?

Alan

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>