Re: init_on_alloc digression: [LSF/MM/BPF TOPIC] Dropping page cache of individual fs

From: John Hubbard <jhubbard@nvidia.com>
To: Adrian Vovk <adrianvovk@gmail.com>, Dave Chinner <david@fromorbit.com>
Cc: Jan Kara <jack@suse.cz>, Matthew Wilcox <willy@infradead.org>,
	Christian Brauner <brauner@kernel.org>,
	lsf-pc@lists.linux-foundation.org, linux-fsdevel@vger.kernel.org,
	linux-mm@kvack.org, linux-btrfs@vger.kernel.org,
	linux-block@vger.kernel.org,
	Christoph Hellwig <hch@infradead.org>
Subject: Re: init_on_alloc digression: [LSF/MM/BPF TOPIC] Dropping page cache of individual fs
Date: Fri, 16 Feb 2024 13:19:40 -0800	[thread overview]
Message-ID: <b6827a5f-ae28-4029-9e91-329e2a9503fc@nvidia.com> (raw)
In-Reply-To: <67eef60c-b0fe-4034-a2e5-b09c7ef38a5a@gmail.com>

On 2/16/24 13:11, Adrian Vovk wrote:
...
>> But init_on_alloc forces the CPU to clear the memory first, because of
>> the belief here that this is somehow required in order to get defense
>> in depth. (True, if you can convince yourself that some parts of the
>> kernel are in a different trust boundary than others. I lack faith
>> here and am not a believer in such make belief boundaries.)
> 
> As far as I can tell init_on_alloc isn't about drawing a trust boundary 
> between parts of the kernel, but about hardening the kernel against 
> mistakes made by developers, i.e. if they forget to initialize some 

So this is writing code in order to protect against other code, in
the same kernel. So now we need some more code in case this new code
forgets to do something, or has a bug.

This will recurse into an infinite amount of code. :)

> memory. If the memory isn't zero'd and the developer forgets to 
> initialize it, then potentially memory under user control (from page 
> cache or so) can control flow of execution in the kernel. Thus, zeroing 
> out the memory provides a second layer of defense even in situations 
> where the first layer (not using uninitialized memory) failed. Thus, 
> defense in depth.

Why not initialize memory at the entry of every function that sees
the page, then, and call it defense-really-in-depth? It's hard to see
where the silliness ends.

> 
> Is this just an NVIDIA embedded thing (AFAIK your desktop/laptop cards 

Nope. Any system that has slow CPU access to fast accelerator memory
would suffer like this. And many are being built.

> don't share memory with the CPU), or would it affect something like 
> Intel/AMD APUs as well?
> 
> If the GPU is so much faster at zeroing out blocks of memory in these 
> systems, maybe the kernel should use the GPU's DMA engine whenever it 
> needs to zero out some blocks of memory (I'm joking, mostly; I can 
> imagine it's not quite so simple)

Yes, it's conceivable to put in a callback hook from the init_on_alloc
so that it could use a driver to fast-zero the memory. Except that
will never be accepted by anyone who accepts your first argument:
this is "protection" against those forgetful, silly driver writers.

thanks,
-- 
John Hubbard
NVIDIA