linux-kernel - Re: [PATCH v21 1/4] mm: add VM_DROPPABLE for designating always lazily freeable mappings

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <ZotIEhO86_RRNOgy@zx2c4.com>
Date: Mon, 8 Jul 2024 03:59:46 +0200
From: "Jason A. Donenfeld" <Jason@...c4.com>
To: Linus Torvalds <torvalds@...ux-foundation.org>
Cc: David Hildenbrand <david@...hat.com>, 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 v21 1/4] mm: add VM_DROPPABLE for designating always
 lazily freeable mappings

Hi Linus,

On Sun, Jul 07, 2024 at 11:19:46AM -0700, Linus Torvalds wrote:
>  (c) we could actually use the PROT_xyz bits, which we have a ton of

As I just wrote to David, I'll move this to PROT_xyz.

By the way, in addition to the PROT_SEM historical artifact, there's
also architecture specific ones like PROT_ADI on SPARC, PROT_SAO on
PowerPC, and PROT_BTI and PROT_MTE on arm64. So the MAP_ vs PROT_
distinction seems kind of blurred anyway.

> And we actually have had the "get signal on access" before: that's
> what VM_DONTCOPY is.
> 
> And it was the *less* useful model, which is why we added
> VM_WIPEONCOPY, because that's the semantics people actually wanted.
> 
> So I think the "signal on thrown out data access" is interesting, but
> not necessarily the *more* interesting case.

FYI, I looked into using VM_DONTCOPY/MADV_DONTFORK for my purposes,
because it could possibly make another problem easier, but I couldn't
figure out how to make it smoothly work.

Specifically, a program has a bunch of threads, and some of them have a
vgetrandom state in use, carved out of the same page. One of the threads
forks. In the VM_WIPEONFORK case, the fork child has to reclaim the
states that were in use by other threads at the time of the fork and
return them to the pool of available slices. In the VM_DONTCOPY case,
that's not necessary, which is kind of nice. But if the program forked
in the signal handler and then returned to an in progress vgetrandom
operation, now there's a signal that needs to be handled internally,
identified as belonging to the internal state areas, and not bubbled up
to other code. This seems difficult and fraught. It's far easier to just
have the memory be zeroed and have the code unconditionally check for
that at the same time it's doing other consistency checks.

So yea it just seems a lot more desirable to have the behavior be
zeroing rather than an asynchronous signal, because code can
straightforwardly deal with that inline.

Jason