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

[Ingo Molnar]

* Larry H. <research@xxxxxxxxxxxxxx> wrote:

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

You need to address my specific concerns instead of referring back 
to an earlier discussion. The patches touch code i maintain and i 
find them (and your latest resend) unacceptable.

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

Naming _is_ a technical issue. Especially here.

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

What you are missing is that your patch makes _no technical sense_ 
if you allow the same information to leak over the kernel stack. 
Kernel stacks can be freed and reused, swapped out and thus 
'exposed'.

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