[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAHk-=wgLWcKq2AdrTmTOxJKn6w4oEpEGdipWAah5Xad5-Yii6Q@mail.gmail.com>
Date: Fri, 6 Jan 2023 13:10:44 -0800
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: Andy Lutomirski <luto@...nel.org>
Cc: "Jason A. Donenfeld" <Jason@...c4.com>,
Yann Droneaud <ydroneaud@...eya.com>,
Ingo Molnar <mingo@...nel.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
patches@...ts.linux.dev, Thomas Gleixner <tglx@...utronix.de>,
Linux Crypto Mailing List <linux-crypto@...r.kernel.org>,
Linux API <linux-api@...r.kernel.org>,
"the arch/x86 maintainers" <x86@...nel.org>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
Adhemerval Zanella Netto <adhemerval.zanella@...aro.org>,
"Carlos O'Donell" <carlos@...hat.com>,
Florian Weimer <fweimer@...hat.com>,
Arnd Bergmann <arnd@...db.de>, Jann Horn <jannh@...gle.com>,
Christian Brauner <brauner@...nel.org>, linux-mm@...ck.org
Subject: Re: [PATCH v14 2/7] mm: add VM_DROPPABLE for designating always
lazily freeable mappings
On Fri, Jan 6, 2023 at 12:54 PM Andy Lutomirski <luto@...nel.org> wrote:
>
> I'm going to suggest a very very different approach: fix secret
> storage in memory for real. That is, don't lock "super secret
> sensitive stuff" into memory, and don't wipe it either. *Encrypt* it.
I don't think you're wrong, but people will complain about key
management, and worry about that part instead.
Honestly, this is what SGX and CPU enclaves is _supposed_ to all do
for you, but then nobody uses it for various reasons.
Linus
Powered by blists - more mailing lists