[lkml]   [2009]   [May]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [patch 0/5] Support for sanitization flag in low-level page allocator

    * Larry H. <> 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


     \ /
      Last update: 2009-05-23 14:53    [W:0.041 / U:1.460 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site