lkml.org 
[lkml]   [2023]   [Jan]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH v14 2/7] mm: add VM_DROPPABLE for designating always lazily freeable mappings
    On Thu, Jan 05, 2023 at 10:57:48PM +0100, Yann Droneaud wrote:
    > Hi,
    >
    > Le 03/01/2023 à 21:44, Jason A. Donenfeld a écrit :
    > > On Tue, Jan 03, 2023 at 12:15:57PM -0800, Linus Torvalds wrote:
    > >> On Tue, Jan 3, 2023 at 12:03 PM Jason A. Donenfeld <Jason@zx2c4.com> wrote:
    > >>> That buffering cannot be done safely currently
    > >> .. again, this is "your semantics" (the (b) in my humbug list), not
    > >> necessarily reality for anybody else.
    > > Yea that's fair. Except, of course, I maintain that my semantics are
    > > important ones. :)
    >
    >
    > I concur.
    >
    > To hold secret material, we need MADV_WIPEONFORK | MADV_DONTDUMP and the side effect of mlock() (pages' content never written to swap), inherited across fork().
    > And I want mlock() without paying the price.
    >
    > Jason's proposed semantics, which I call MADV_WIPEONSWAP, provide a mean to hold /unlimited/ amount secrets in userspace memory (not limited by RLIMIT_MEMLOCK).
    > The only constraint for userspace is to handle the case pages are wiped, which is already the case of userspace arc4random()'s implementation.

    If you're actually serious about wanting a generic mechanism for
    userspace, I think the moral of yesterday's poo-poo'ing all over this
    cool new idea is that the Linux innercircle doesn't really care for
    "security things" as a motivator and just takes the shortest and easiest
    route toward swatting it away like a gadfly, assuming that the concerns
    are unreal or niche or paranoid or whatever. This is obviously nothing
    new - it's an old complaint beaten to death for years, with people who
    are diehard it about eventually getting burnt out and leaving. So,
    practically speaking, if you want this to exist, I think you have to
    find some other cool use cases. Like, see if the database cache people
    would actually love this. Or if it could be used as an opportunistic
    renderer cache in Chrome that wouldn't result in OOMing with lots of
    tabs. Or if shared process compiler servers could benefit from it.
    "Droppable cache" is likely useful lots of places. So just find
    SOMETHING that doesn't mean having to convince folks of a new security
    model that justifies tickling mm/ innards in uncomfortable ways.

    Jason

    \
     
     \ /
      Last update: 2023-03-26 23:29    [W:4.627 / U:0.172 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site