From: Uladzislau Rezki <urezki@gmail.com>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Waiman Long <longman@redhat.com>, Joe Perches <joe@perches.com>,
Andrew Morton <akpm@linux-foundation.org>,
David Howells <dhowells@redhat.com>,
Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>,
James Morris <jmorris@namei.org>,
"Serge E. Hallyn" <serge@hallyn.com>,
Linux-MM <linux-mm@kvack.org>,
keyrings@vger.kernel.org,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Matthew Wilcox <willy@infradead.org>,
David Rientjes <rientjes@google.com>
Subject: Re: [PATCH v3] mm: Add kvfree_sensitive() for freeing sensitive data objects
Date: Tue, 07 Apr 2020 21:24:47 +0000 [thread overview]
Message-ID: <20200407212447.GA29554@pc636> (raw)
In-Reply-To: <CAHk-=whV5Z4XioUOW0UM-PBrW7iqb0HwWKQU5Vn8b5pmsDm=Ww@mail.gmail.com>
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
WARNING: multiple messages have this Message-ID (diff)
From: Uladzislau Rezki <urezki@gmail.com>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Waiman Long <longman@redhat.com>, Joe Perches <joe@perches.com>,
Andrew Morton <akpm@linux-foundation.org>,
David Howells <dhowells@redhat.com>,
Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>,
James Morris <jmorris@namei.org>,
"Serge E. Hallyn" <serge@hallyn.com>,
Linux-MM <linux-mm@kvack.org>,
keyrings@vger.kernel.org,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Matthew Wilcox <willy@infradead.org>,
David Rientjes <rientjes@google.com>
Subject: Re: [PATCH v3] mm: Add kvfree_sensitive() for freeing sensitive data objects
Date: Tue, 7 Apr 2020 23:24:47 +0200 [thread overview]
Message-ID: <20200407212447.GA29554@pc636> (raw)
In-Reply-To: <CAHk-=whV5Z4XioUOW0UM-PBrW7iqb0HwWKQU5Vn8b5pmsDm=Ww@mail.gmail.com>
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
next prev parent reply other threads:[~2020-04-07 21:24 UTC|newest]
Thread overview: 47+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-04-07 20:03 [PATCH v3] mm: Add kvfree_sensitive() for freeing sensitive data objects Waiman Long
2020-04-07 20:03 ` Waiman Long
2020-04-07 20:09 ` Linus Torvalds
2020-04-07 20:09 ` Linus Torvalds
2020-04-07 20:19 ` David Howells
2020-04-07 20:19 ` David Howells
2020-04-07 20:21 ` David Howells
2020-04-07 20:21 ` David Howells
2020-04-07 20:21 ` David Howells
2020-05-05 20:35 ` Andrew Morton
2020-05-05 20:35 ` Andrew Morton
2020-05-06 1:29 ` Waiman Long
2020-05-06 1:29 ` Waiman Long
2020-04-07 20:24 ` Waiman Long
2020-04-07 20:24 ` Waiman Long
2020-04-07 20:31 ` Joe Perches
2020-04-07 20:31 ` Joe Perches
2020-04-07 20:45 ` Waiman Long
2020-04-07 20:45 ` Waiman Long
2020-04-07 21:01 ` Linus Torvalds
2020-04-07 21:01 ` Linus Torvalds
2020-04-07 21:24 ` Uladzislau Rezki [this message]
2020-04-07 21:24 ` Uladzislau Rezki
2020-04-07 21:30 ` Linus Torvalds
2020-04-07 21:30 ` Linus Torvalds
2020-04-07 22:12 ` Matthew Wilcox
2020-04-07 22:12 ` Matthew Wilcox
2020-04-08 0:35 ` Joe Perches
2020-04-08 0:35 ` Joe Perches
2020-04-08 13:38 ` Jarkko Sakkinen
2020-04-08 13:38 ` Jarkko Sakkinen
2020-05-01 23:22 ` Eric Biggers
2020-05-01 23:22 ` Eric Biggers
2020-05-04 2:57 ` Waiman Long
2020-05-04 2:57 ` Waiman Long
2020-05-14 11:00 ` Balbir Singh
2020-05-14 11:00 ` Balbir Singh
2020-05-14 12:00 ` Matthew Wilcox
2020-05-14 12:00 ` Matthew Wilcox
2020-05-14 12:08 ` Joe Perches
2020-05-14 12:08 ` Joe Perches
2020-05-17 0:27 ` Balbir Singh
2020-05-17 0:27 ` Balbir Singh
2020-05-17 0:44 ` Matthew Wilcox
2020-05-17 0:44 ` Matthew Wilcox
2020-05-18 2:39 ` Waiman Long
2020-05-18 2:39 ` Waiman Long
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20200407212447.GA29554@pc636 \
--to=urezki@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=dhowells@redhat.com \
--cc=jarkko.sakkinen@linux.intel.com \
--cc=jmorris@namei.org \
--cc=joe@perches.com \
--cc=keyrings@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=longman@redhat.com \
--cc=rientjes@google.com \
--cc=serge@hallyn.com \
--cc=torvalds@linux-foundation.org \
--cc=willy@infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.