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: <CAKmqyKNei==TWCFASFvBC48g_DsFwncmO=KYH_i9JrpFmeRu+w@mail.gmail.com>
Date: Fri, 28 Feb 2025 12:27:36 +1000
From: Alistair Francis <alistair23@...il.com>
To: Greg KH <gregkh@...uxfoundation.org>
Cc: Miguel Ojeda <miguel.ojeda.sandonis@...il.com>, Alice Ryhl <aliceryhl@...gle.com>, 
	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, 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 Fri, Feb 28, 2025 at 5:33 AM Greg KH <gregkh@...uxfoundation.org> wrote:
>
> On Thu, Feb 27, 2025 at 05:45:02PM +0100, Miguel Ojeda wrote:
> > On Thu, Feb 27, 2025 at 1:01 PM Greg KH <gregkh@...uxfoundation.org> wrote:
> > >
> > > 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?

This I can address with something like Alice mentioned earlier to
ensure the C and Rust functions stay in sync.

> >
> > What you were probably remembering is that it still needs to be
> > justified, i.e. we don't want to generally/freely start replacing
> > "individual functions" and doing FFI both ways everywhere, i.e. the
> > goal is to build safe abstractions wherever possible.
>
> Ah, ok, that's what I was remembering.
>
> Anyway, the "pass a void blob from C into rust" that this patch is doing
> feels really odd to me, and hard to verify it is "safe" at a simple
> glance.

I agree, it's a bit odd. Ideally I would like to use a sysfs binding,
but there isn't one today.

I had a quick look and a Rust sysfs binding implementation seems like
a lot of work, which I wasn't convinced I wanted to invest in for this
series. This is only a single sysfs attribute and I didn't want to
slow down this series on a whole sysfs Rust implementation.

If this approach isn't ok for now, I will just drop the sysfs changes
from the series so the SPDM implementation doesn't stall on sysfs
changes. Then come back to the sysfs attributes in the future.

So the high level question, is "pass[ing] a void blob from C into
rust" ok or should I defer for a future safer implementation?

Alistair

>
> thanks,
>
> greg k-h