linux-kernel - Re: [RFC v2 09/20] PCI/CMA: Expose in sysfs whether devices are authenticated

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: <2025022741-handwoven-game-df08@gregkh>
Date: Thu, 27 Feb 2025 06:03:02 -0800
From: Greg KH <gregkh@...uxfoundation.org>
To: Alice Ryhl <aliceryhl@...gle.com>
Cc: Alistair Francis <alistair@...stair23.me>, linux-cxl@...r.kernel.org,
	linux-kernel@...r.kernel.org, lukas@...ner.de,
	linux-pci@...r.kernel.org, bhelgaas@...gle.com,
	Jonathan.Cameron@...wei.com, rust-for-linux@...r.kernel.org,
	akpm@...ux-foundation.org, boqun.feng@...il.com,
	bjorn3_gh@...tonmail.com, wilfred.mallawa@....com, ojeda@...nel.org,
	alistair23@...il.com, a.hindborg@...nel.org, tmgross@...ch.edu,
	gary@...yguo.net, alex.gaynor@...il.com, benno.lossin@...ton.me,
	Alistair Francis <alistair.francis@....com>
Subject: Re: [RFC v2 09/20] PCI/CMA: Expose in sysfs whether devices are
 authenticated

On Thu, Feb 27, 2025 at 01:11:01PM +0100, Alice Ryhl wrote:
> On Thu, Feb 27, 2025 at 1:01 PM Greg KH <gregkh@...uxfoundation.org> wrote:
> >
> > On Thu, Feb 27, 2025 at 12:52:02PM +0100, Alice Ryhl wrote:
> > > On Thu, Feb 27, 2025 at 12:17 PM Greg KH <gregkh@...uxfoundation.org> wrote:
> > > >
> > > > On Thu, Feb 27, 2025 at 01:09:41PM +1000, Alistair Francis wrote:
> > > > > +     return rust_authenticated_show(spdm_state, buf);
> > > >
> > > > Here you have C code calling into Rust code.  I'm not complaining about
> > > > it, but I think it will be the first use of this, and I didn't think
> > > > that the rust maintainers were willing to do that just yet.
> > > >
> > > > Has that policy changed?
> > > >
> > > > The issue here is that the C signature for this is not being
> > > > auto-generated, you have to manually keep it in sync (as you did above),
> > > > with the Rust side.  That's not going to scale over time at all, you
> > > > MUST have a .h file somewhere for C to know how to call into this and
> > > > for the compiler to check that all is sane on both sides.
> > > >
> > > > And you are passing a random void * into the Rust side, what could go
> > > > wrong?  I think this needs more thought as this is fragile-as-f***.
> > >
> > > I don't think we have a policy against it? I'm pretty sure the QR code
> > > thing does it.
> >
> > Sorry, you are right, it does, and of course it happens (otherwise how
> > would bindings work), but for small functions like this, how is the C
> > code kept in sync with the rust side?  Where is the .h file that C
> > should include?
> 
> I don't think there is tooling for it today. We need the opposite of
> bindgen, which does exist in a tool called cbindgen. Unfortunately,
> cbindgen is written to only work in cargo-based build systems, so we
> cannot use it.
> 
> One trick you could do is write the signature in a header file, and
> then compare what bindgen generates to the real signature like this:
> 
> const _: () = {
>     if true {
>         bindings::my_function
>     } else {
>         my_function
>     };
> };
> 
> This would only compile if the two function pointers have the same signature.

That feels just wrong :(

As this seems like it's going to be a longer-term issue, has anyone
thought of how it's going to be handled?  Build time errors when
functions change is the key here, no one remembers to manually verify
each caller to verify the variables are correct anymore, that would be a
big step backwards.

thanks,

greg k-h