[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CALCETrVJFefyDT6U3QoHdZvNh=3nqk=3AK88eRuqdn4W4t8vsA@mail.gmail.com>
Date: Fri, 7 Jun 2024 11:40:33 -0700
From: Andy Lutomirski <luto@...capital.net>
To: "Jason A. Donenfeld" <Jason@...c4.com>
Cc: linux-kernel@...r.kernel.org, patches@...ts.linux.dev, tglx@...utronix.de,
linux-crypto@...r.kernel.org, linux-api@...r.kernel.org, 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>, David Hildenbrand <dhildenb@...hat.com>, linux-mm@...ck.org
Subject: Re: [PATCH v16 1/5] mm: add VM_DROPPABLE for designating always
lazily freeable mappings
On Tue, May 28, 2024 at 5:24 AM Jason A. Donenfeld <Jason@...c4.com> wrote:
>
> The vDSO getrandom() implementation works with a buffer allocated with a
> new system call that has certain requirements:
>
> - It shouldn't be written to core dumps.
> * Easy: VM_DONTDUMP.
I'll bite: why shouldn't it be written to core dumps?
The implementation is supposed to be forward-secret: an attacker who
gets the state can't predict prior outputs. And a core-dumped process
is dead: there won't be future outputs.
Powered by blists - more mailing lists