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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20090530054856.GG29711@oblivion.subreption.com>
Date:	Fri, 29 May 2009 22:48:56 -0700
From:	"Larry H." <research@...reption.com>
To:	Arjan van de Ven <arjan@...radead.org>
Cc:	Peter Zijlstra <peterz@...radead.org>,
	Alan Cox <alan@...rguk.ukuu.org.uk>,
	Ingo Molnar <mingo@...e.hu>, Rik van Riel <riel@...hat.com>,
	linux-kernel@...r.kernel.org, Linus Torvalds <torvalds@...l.org>,
	linux-mm@...ck.org, Ingo Molnar <mingo@...hat.com>,
	pageexec@...email.hu
Subject: Re: [patch 0/5] Support for sanitization flag in low-level page
	allocator

On 07:32 Fri 29 May     , Arjan van de Ven wrote:
> On Thu, 28 May 2009 21:36:01 +0200
> Peter Zijlstra <peterz@...radead.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.

> that is why I said it's controversial.
> 
> BUT if you zero on free anyway...
> 
> And I don't think it's as big a deal as you make it.
> Why?
> 
> We recycle pages in LIFO order. And L2 caches are big.
> 
> 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.

> The other thing is that zero-on-allocate puts the WHOLE page in L1,
> while you can study how much of that page is actually used on average,
> and it'll be a percentage lower than 100%.
> In fact, if it IS 100%, you shouldn't have put it in L1 because the app
> does that anyway. If it is not 100% you just blew a chunk of your L1
> for no value.
> 
> Don't get me wrong, I'm not arguing that zero-on-free is better, I'm
> just trying to point out that the "advantage" of zero-on-allocate isn't
> nearly as big as people sometimes think it is...

Performance-wise, I agree with you here. Security-wise, I assure
you that clearing on allocation time is most certainly hopeless.

If there's further room for improvement in the patch, and something can
be optimized, I will do my best with it. I won't be able to provide any
updates until Sunday, likely. I'll do a kernbench, if someone has
further benchmarks to suggest, please let me know.

	Larry

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