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]

Date:	Fri, 22 May 2009 19:21:58 +0100
From:	Alan Cox <alan@...rguk.ukuu.org.uk>
To:	"Larry H." <research@...reption.com>
Cc:	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

> I'm going to present a very short analysis for different historic leaks
> which had little to do with 'padding bytes in stack', but more like

I wouldn't dispute both classes exist - and a lot of the padding leaks
probably never got a CVE either (eg some of the tty ones just got fixed)

> If the caller provided the page already allocated, the GFP_ZERO
> allocation never happened, and the page was never cleared. Interesting
> issue since my patch basically ensures this doesn't happen. Nevermind.

Which patch are we talking about ? I'm all for a security option which
clears *all* objects on freeing them (actually the poison debug is pretty
close to this). That would fix these examples too.

> At least it's not entirely deceitful. It's definitely dereferencing
> "random memory".

Which could be another task stack you didn't clear - yes ?

> was used to leak kernel memory to userland after a page was allocated at
> NULL by the exploit abusing the issue.

Including task stacks yes ?

And task stacks contain copies of important data yes ?

> My intention here is to make the kernel more secure, not proving you
> wrong or right.

Ditto - which is why I'm coming from the position of an "if we free it
clear it" option. If you need that kind of security the cost should be
more than acceptable - especially with modern processors that can do
cache bypass on the clears.

> You are a smart fellow and I respect your technical and kernel development
> acumen. Smart people don't waste their time on meaningless banter.
> 
> I'll have the modified patches ready in an hour or so, hopefully.

Excellent.

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