lkml.org 
[lkml]   [2020]   [Apr]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    Date
    SubjectRe: [PATCH v3] mm: Add kvfree_sensitive() for freeing sensitive data objects
    On Tue, Apr 07, 2020 at 02:01:01PM -0700, Linus Torvalds wrote:
    > On Tue, Apr 7, 2020 at 1:45 PM Waiman Long <longman@redhat.com> wrote:
    > >
    > > If the memory is really virtually mapped, the only way to find out the
    > > size of the object is to use find_vm_area() which can be relatively high
    > > cost and no simple helper function is available.
    >
    > We _could_ just push it down to a "vfree_sensitive()", and do it
    > inside the vfree logic. That ends up obviously figuring out the size
    > of the area eventually.
    >
    > But since the vmalloc data structures fundamentally aren't irq-safe,
    > vfree() actually has magical things like "if called in an interrupt,
    > we'll delay it to work context".
    >
    Just some thoughts. Sorry for jumping in.

    Seems like there is only one place where we can "sleep". I mean when we
    call vfree(). That is free_vmap_area_noflush() -> try_purge_vmap_area_lazy().
    Basically try_purge_vmap_area_lazy() can call the schedule() what is not
    allowed for IRQs. Instead of inlining the try_purge_vmap_area_lazy()
    into current context we can schedule_work(). And i think it makes sense
    from many point of views.

    Also, we can end up in zeroed non-existance vmap area if we do not find_vmap_area().

    Thanks!

    --
    Vlad Rezki

    \
     
     \ /
      Last update: 2020-04-07 23:25    [W:2.157 / U:0.228 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site