Received-SPF: pass (google.com: domain of linux-kernel+bounces-58802-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45e3:2400::1 as permitted sender) client-ip=2604:1380:45e3:2400::1;
From: Valentin Obst <kernel@valentinobst.de>
To: aliceryhl@google.com
Cc: a.hindborg@samsung.com,
	akpm@linux-foundation.org,
	alex.gaynor@gmail.com,
	arnd@arndb.de,
	arve@android.com,
	benno.lossin@proton.me,
	bjorn3_gh@protonmail.com,
	boqun.feng@gmail.com,
	brauner@kernel.org,
	cmllamas@google.com,
	gary@garyguo.net,
	gregkh@linuxfoundation.org,
	joel@joelfernandes.org,
	keescook@chromium.org,
	linux-kernel@vger.kernel.org,
	linux-mm@kvack.org,
	maco@android.com,
	ojeda@kernel.org,
	rust-for-linux@vger.kernel.org,
	surenb@google.com,
	tkjos@android.com,
	viro@zeniv.linux.org.uk,
	wedsonaf@gmail.com,
	Valentin Obst <kernel@valentinobst.de>
Subject: Re: [PATCH v2 3/4] rust: uaccess: add typed accessors for userspace pointers
Date: Thu,  8 Feb 2024 23:57:48 +0100
Message-ID: <20240208225748.12031-1-kernel@valentinobst.de>
In-Reply-To: <20240208-alice-mm-v2-3-d821250204a6@google.com>
References: <20240208-alice-mm-v2-3-d821250204a6@google.com>
Precedence: bulk
MIME-Version: 1.0
UI-OutboundReport: notjunk:1;M01:P0:JeE0MJLO5g4=;QYl3ENKI9UZfpQq/P5YUuUdBhDk
 CHaqbuWqRbjB/K+gI8E39rZOnEEQaZOiJr1iHfN8YFkIeO2nYgMz/Miol9SXLlv98JMWwROaI
 pU8wNQSxhNUUBkU1uqvwYa1HNW2Tk0d4hK9Aaa3U0ry0tR3iDEbGSta/vhebSN4Bi489H4sc1
 s2tQse4tkYpmihgK2s3UNyRmAkuUtRbeS9DK+GprFtXOEvORBWdAPjuEg5kLIHUfIVPWsAIXD
 gG5AfMlhYqOe0bHOqBxnkGW3+IFsC0+CMA2j2Wy2ESzlM5sh/EQvmn6aAzOnBg+Vo9sTi88br
 3QTvy0+l+RGmu6Z842cJIghRPSOMDcwp0Zb/dawvoYbFl5habYIGJybhNR/MsPIs+l8oNEHW7
 wg4NrmbTssxgmTwOH21l+thRZtRzFygZ8VKdPl5Hjo6E80c0ubuG5v2Fv3aGyAr3njOVzTI0T
 Wj9S9pzH1RL3FDbIrpuJXwyfMLElSNg8SWEd0WMSTTDtbkPO6/ePONogL6yEbZ90z5LSwq1SW
 FCbsRq7RnOZxFg4Seaa28UT9oN2o/HYkmnRMxt6aXRX9Sm2p2otbFp6KpzYCihymNLcF7SimK
 XT7mt2xiNBPf2IzQ6Q+P5LWigBNrA4W0Q3ekU1SuBqyvWCLXGtIjx06xZkgYZuIIEdyqafW6q
 xakPq80+bEGnomh2p9+nNfNx2FwVejkuvPS7emCH4KEh4EItxUpgkmFLcW1SXYAnNY4RrstMg
 Jblkt3HHcI66NLlI/4upFX9J92a2HYzfHk6SLrB0h71LKJt0ETlfLo=

> +/// If a struct implements this trait, then it is okay to copy it byte-for-byte
> +/// to userspace. This means that it should not have any padding, as padding
> +/// bytes are uninitialized. Reading uninitialized memory is not just undefined
> +/// behavior, it may even lead to leaking sensitive information on the stack to
> +/// userspace.

This feels a bit too restrictive to me. Isn't it okay to copy types with
padding if it is ensured that the padding is always initialized?

I recall that in C one occasionally does a `memset` for structs that are
copied to user space. I imagine that one could have a Rust
abstraction/macro that makes it easy to define custom types that can
always guarantee that all padding bytes are initialized. Such types
would then qualify for being copied to user space if all field do so as
well.

This could be a significant quality-of-life improvement for drivers
as it can be tedious to define struct without padding.

	- Best Valentin