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-next>] [day] [month] [year] [list]

Date:	Fri, 22 May 2009 04:38:09 -0700
From:	"Larry H." <research@...reption.com>
To:	Ingo Molnar <mingo@...e.hu>
Cc:	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>,
	Alan Cox <alan@...rguk.ukuu.org.uk>, pageexec@...email.hu
Subject: Re: [patch 0/5] Support for sanitization flag in low-level page
	allocator

NOTE: Let's keep the PaX Team on CC from now on, they might have further
input to this discussion. (pageexec at freemail dot hu)

On 09:34 Fri 22 May     , Ingo Molnar wrote:
> The whole kernel contains data that 'should not be leaked'.
> _If_ any of this is done, i'd _very_ strongly suggest to describe it 
> by what it does, not by what its subjective security attribute is.
> 
> 'PG_eyes_only' or 'PG_eagle_azf_compartmented' is silly naming. It 
> is silly because it hardcodes one particular expectation/model of 
> 'security'.
> 
> GFP_NON_PERSISTENT & PG_non_persistent is a _lot_ better, because it 
> is a technical description of how information spreads. (which is the 
> underlying principle of every security model)
>
> That name alone tells us everyting what this does: it does not allow 
> this data to reach or touch persistent storage. It wont be swapped 
> and it wont by saved by hibernation. It will also be cleared when 
> freed, to achieve its goal of never touching persistent storage.

The problem is that these patches have a more broad purpose and I never
mentioned persistent storage as one of them (initially). Check earlier
messages to see what has been discussed so far.

Regarding the naming changes, those have been done as of Rik's comments
and I would rather focus on the technical and implementation side now.

> In-kernel crypto key storage using GFP_NON_PERSISTENT makes some 
> sense - as long as the kernel stack itself is mared 
> GFP_NON_PERSISTENT as well ... which is quite hairy from a 
> performance point of view: we _dont_ want to clear the full stack 
> page for every kernel thread exiting.

Burning the stack there is beyond overkill.

> For user-space keys it is easier to isolate the spreading of that 
> data, because the kernel never reads it. So MAP_NON_PERSISTENT makes 
> some sense.

Yes, but that should be incremental patch once we have settled down on
the other ones.

	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/