[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <699292.1586294051@warthog.procyon.org.uk>
Date: Tue, 07 Apr 2020 22:14:11 +0100
From: David Howells <dhowells@...hat.com>
To: Linus Torvalds <torvalds@...ux-foundation.org>
Cc: dhowells@...hat.com, Joe Perches <joe@...ches.com>,
Waiman Long <longman@...hat.com>,
Andrew Morton <akpm@...ux-foundation.org>,
Jarkko Sakkinen <jarkko.sakkinen@...ux.intel.com>,
James Morris <jmorris@...ei.org>,
"Serge E. Hallyn" <serge@...lyn.com>,
Linux-MM <linux-mm@...ck.org>, keyrings@...r.kernel.org,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
Matthew Wilcox <willy@...radead.org>,
David Rientjes <rientjes@...gle.com>
Subject: Re: [PATCH v2] mm: Add kvfree_sensitive() for freeing sensitive data objects
Linus Torvalds <torvalds@...ux-foundation.org> wrote:
> So the _real_ prototype for 'free()'-like operations should be something like
>
> void free(const volatile killed void *ptr);
>
> where that "killed" also tells the compiler that the pointer lifetime
> is dead, so that using it afterwards is invalid. So that the compiler
> could warn us about some of the most trivial use-after-free cases.
It might be worth asking the compiler folks to give us an __attribute__ for
that - even if they don't do anything with it immediately. So we might have
something like:
void free(const volatile void *ptr) __attribute__((free(1)));
There are some for allocation functions, some of which we use, though I'm not
sure we do so as consistently as we should (should inline functions like
kcalloc() have them, for example?).
David
Powered by blists - more mailing lists