linux-kernel - Re: [PATCH v2 16/19] gendwarfksyms: Add support for reserved structure fields

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: <2024082356-stowing-endowment-555b@gregkh>
Date: Fri, 23 Aug 2024 07:53:22 +0800
From: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
To: Benno Lossin <benno.lossin@...ton.me>
Cc: Matthew Maurer <mmaurer@...gle.com>,
	Sami Tolvanen <samitolvanen@...gle.com>,
	Masahiro Yamada <masahiroy@...nel.org>,
	Luis Chamberlain <mcgrof@...nel.org>,
	Miguel Ojeda <ojeda@...nel.org>,
	Alex Gaynor <alex.gaynor@...il.com>,
	Wedson Almeida Filho <wedsonaf@...il.com>,
	Gary Guo <gary@...yguo.net>, Petr Pavlu <petr.pavlu@...e.com>,
	Neal Gompa <neal@...pa.dev>, Hector Martin <marcan@...can.st>,
	Janne Grunau <j@...nau.net>, Asahi Linux <asahi@...ts.linux.dev>,
	linux-kbuild@...r.kernel.org, linux-kernel@...r.kernel.org,
	linux-modules@...r.kernel.org, rust-for-linux@...r.kernel.org
Subject: Re: [PATCH v2 16/19] gendwarfksyms: Add support for reserved
 structure fields

On Thu, Aug 22, 2024 at 12:00:15PM +0000, Benno Lossin wrote:
> > Here's one example in the android tree where 4 64bit fields are reserved
> > for future abi changes:
> > 	https://android.googlesource.com/kernel/common/+/refs/heads/android12-5.10/include/linux/fs.h#421
> > 
> > And here's a different place where a field is being used with many
> > remaining for future use:
> > 	https://android.googlesource.com/kernel/common/+/refs/heads/android12-5.10/include/linux/sched.h#1379
> > 
> > And also, we want/need lots of other space reservation at times, look at
> > how "Others" can get access to reserved areas in structures that need to
> > be done in an abi-safe way:
> > 	https://android.googlesource.com/kernel/common/+/refs/heads/android12-5.10/include/linux/sched.h#1375
> 
> Let me correct myself, it's only possible to replace one `KAbiReserved`
> by one new field. You can have as many fields of type `KAbiReserved` as
> you want. The thing that you can't do is replace a single `KAbiReserved`
> field by multiple (well you can, but then you have to change the sites
> that use it).

That's odd/foolish, why would that be the case?  Isn't that exactly what
a union is for?  How are you going to know ahead of time what size types
to save space for?

All we really want to do here is "pad out this structure by X bytes" and
then later "take X bytes to represent this variable" at a later point in
time.

Surely rust can do that, right?  :)

> > All of this also needs to be possible in any structures that are
> > exported by rust code if vendors want to have a way to track and ensure
> > that abis do not change over time, just like they can today in C code.
> 
> All of those structs need to be `repr(C)`, otherwise they don't
> have a stable layout to begin with.

Do we have any way to enforce at build time that exports from rust code
are in this format to ensure that this will work properly going forward?
I guess someone is going to have to write the first api in rust that
actually gets used before we worry about this...

thanks,

greg k-h