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

[Pavel Machek <pavel@ucw.cz>]

Hi!

> > > 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.
> 
> We can't find every crash bug either, yet we still ship the kernel and
> people actually use it too.
> 
> What makes these security bugs so much more important than all the other
> ones?

Impact of normal bug is crash -- solved by reboot.

Impact of nasty bug is data corruption -- very rare, solved by
reinstall.

Impact of security bug is 'it is not your machine any more' (or worse,
as in 'it is not your bank account any more') -- reinstall needed,
too, and maybe worse.

So yes, I believe we should do some memory clearing.

> As long as that openoffice or firefox instance keeps running, there's
> nothing in the world the kernel can do to make it more secure.

True.

> If you really write documents that sekrit you simply shouldn't be using
> such software but use an editor that is written by people as paranoid as
> seems to be advocated here.

I may avoid openoffice but I'd still like vi on linux system. 
								Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

--
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>