[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20240208225748.12031-1-kernel@valentinobst.de>
Date: Thu, 8 Feb 2024 23:57:48 +0100
From: Valentin Obst <kernel@...entinobst.de>
To: aliceryhl@...gle.com
Cc: a.hindborg@...sung.com,
akpm@...ux-foundation.org,
alex.gaynor@...il.com,
arnd@...db.de,
arve@...roid.com,
benno.lossin@...ton.me,
bjorn3_gh@...tonmail.com,
boqun.feng@...il.com,
brauner@...nel.org,
cmllamas@...gle.com,
gary@...yguo.net,
gregkh@...uxfoundation.org,
joel@...lfernandes.org,
keescook@...omium.org,
linux-kernel@...r.kernel.org,
linux-mm@...ck.org,
maco@...roid.com,
ojeda@...nel.org,
rust-for-linux@...r.kernel.org,
surenb@...gle.com,
tkjos@...roid.com,
viro@...iv.linux.org.uk,
wedsonaf@...il.com,
Valentin Obst <kernel@...entinobst.de>
Subject: Re: [PATCH v2 3/4] rust: uaccess: add typed accessors for userspace pointers
> +/// 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
Powered by blists - more mailing lists