On Fri, 2009-05-29 at 22:48 -0700, Larry H. wrote:
quoted text
> On 07:32 Fri 29 May     , Arjan van de Ven wrote:
> > On Thu, 28 May 2009 21:36:01 +0200
> > Peter Zijlstra <peterz@infradead.org> wrote:
> > 
> > > > ... and if we zero on free, we don't need to zero on allocate.
> > > > While this is a little controversial, it does mean that at least
> > > > part of the cost is just time-shifted, which means it'll not be TOO
> > > > bad hopefully...
> > > 
> > > zero on allocate has the advantage of cache hotness, we're going to
> > > use the memory, why else allocate it.
> 
> Because zero on allocate kills the very purpose of this patch and it has
> obvious security implications. Like races (in information leak
> scenarios, that is). What happens in-between the release of the page and
> the new allocation that yields the same page? What happens if no further
> allocations happen in a while (that can return the old page again)?
> That's the idea.

I don't get it, these are in-kernel data leaks, you need to be able to
run kernel code to exploit these, if someone can run kernel code, you've
lost anyhow.

Why waste time on this?

quoted text
> > So if you zero on free, the next allocation will reuse the zeroed page.
> > And due to LIFO that is not too far out "often", which makes it likely
> > the page is still in L2 cache.
> 
> Thanks for pointing this out clearly, Arjan.

Thing is, the time between allocation and use is typically orders of
magnitude less than between free and use. 


Really, get a life, go fix real bugs. Don't make our kernel slower for
wanking rights.

--
unsubscribe notice
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/