From: Greg KH <gregkh@linuxfoundation.org>
To: Alistair Francis <alistair23@gmail.com>
Cc: Miguel Ojeda <miguel.ojeda.sandonis@gmail.com>,
Alice Ryhl <aliceryhl@google.com>,
Alistair Francis <alistair@alistair23.me>,
linux-cxl@vger.kernel.org, linux-kernel@vger.kernel.org,
lukas@wunner.de, linux-pci@vger.kernel.org, bhelgaas@google.com,
Jonathan.Cameron@huawei.com, rust-for-linux@vger.kernel.org,
akpm@linux-foundation.org, boqun.feng@gmail.com,
bjorn3_gh@protonmail.com, wilfred.mallawa@wdc.com,
ojeda@kernel.org, a.hindborg@kernel.org, tmgross@umich.edu,
gary@garyguo.net, alex.gaynor@gmail.com, benno.lossin@proton.me,
Alistair Francis <alistair.francis@wdc.com>
Subject: Re: [RFC v2 09/20] PCI/CMA: Expose in sysfs whether devices are authenticated
Date: Fri, 28 Feb 2025 20:27:10 -0800 [thread overview]
Message-ID: <2025022851-usual-backshift-7ea6@gregkh> (raw)
In-Reply-To: <CAKmqyKNei==TWCFASFvBC48g_DsFwncmO=KYH_i9JrpFmeRu+w@mail.gmail.com>
On Fri, Feb 28, 2025 at 12:27:36PM +1000, Alistair Francis wrote:
> On Fri, Feb 28, 2025 at 5:33 AM Greg KH <gregkh@linuxfoundation.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@linuxfoundation.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.
Yes, that looks to be fixed up now and should not be an issue.
> > > 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.
Please do that, we can revisit the sysfs stuff later.
> 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?
I don't think we want random void * blobs being passed between C and
Rust like that as ensuring that both sides really know what is happening
and keep that in sync is going to be impossible over time. Type safety
is our friend :)
thanks,
greg k-h
next prev parent reply other threads:[~2025-03-01 5:32 UTC|newest]
Thread overview: 47+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-02-27 3:09 [RFC v2 00/20] lib: Rust implementation of SPDM Alistair Francis
2025-02-27 3:09 ` [RFC v2 01/20] X.509: Make certificate parser public Alistair Francis
2025-02-27 3:09 ` [RFC v2 02/20] X.509: Parse Subject Alternative Name in certificates Alistair Francis
2025-02-27 3:09 ` [RFC v2 03/20] X.509: Move certificate length retrieval into new helper Alistair Francis
2025-02-27 3:09 ` [RFC v2 04/20] certs: Create blacklist keyring earlier Alistair Francis
2025-02-27 3:09 ` [RFC v2 05/20] lib: rspdm: Initial commit of Rust SPDM Alistair Francis
2025-02-27 3:09 ` [RFC v2 06/20] PCI/CMA: Authenticate devices on enumeration Alistair Francis
2025-02-27 3:09 ` [RFC v2 07/20] PCI/CMA: Validate Subject Alternative Name in certificates Alistair Francis
2025-02-27 3:09 ` [RFC v2 08/20] PCI/CMA: Reauthenticate devices on reset and resume Alistair Francis
2025-02-27 3:09 ` [RFC v2 09/20] PCI/CMA: Expose in sysfs whether devices are authenticated Alistair Francis
2025-02-27 11:16 ` Greg KH
2025-02-27 11:52 ` Alice Ryhl
2025-02-27 12:00 ` Greg KH
2025-02-27 12:11 ` Alice Ryhl
2025-02-27 14:03 ` Greg KH
2025-02-27 16:47 ` Miguel Ojeda
2025-02-27 19:31 ` Greg KH
2025-02-28 8:49 ` Miguel Ojeda
2025-02-27 16:46 ` Miguel Ojeda
2025-02-27 16:45 ` Miguel Ojeda
2025-02-27 19:32 ` Greg KH
2025-02-28 2:27 ` Alistair Francis
2025-03-01 4:27 ` Greg KH [this message]
2025-03-05 19:54 ` Dan Williams
2025-03-07 1:04 ` Alistair Francis
2025-03-07 23:37 ` Dan Williams
2025-03-09 22:57 ` Alistair Francis
2025-02-27 22:42 ` Lukas Wunner
2025-02-28 1:39 ` Greg KH
2025-02-28 2:55 ` Alistair Francis
2025-03-01 4:33 ` Greg KH
2025-03-01 18:01 ` Lukas Wunner
2025-02-27 3:09 ` [RFC v2 10/20] lib: rspdm: Support SPDM get_version Alistair Francis
2025-02-27 3:09 ` [RFC v2 11/20] lib: rspdm: Support SPDM get_capabilities Alistair Francis
2025-02-27 3:09 ` [RFC v2 12/20] lib: rspdm: Support SPDM negotiate_algorithms Alistair Francis
2025-02-27 3:09 ` [RFC v2 13/20] lib: rspdm: Support SPDM get_digests Alistair Francis
2025-02-27 3:09 ` [RFC v2 14/20] lib: rspdm: Support SPDM get_certificate Alistair Francis
2025-02-27 10:58 ` Greg KH
2025-02-27 3:09 ` [RFC v2 15/20] crypto: asymmetric_keys - Load certificate parsing early in boot Alistair Francis
2025-02-27 3:09 ` [RFC v2 16/20] KEYS: Load keyring and certificates " Alistair Francis
2025-02-27 3:09 ` [RFC v2 17/20] PCI/CMA: Support built in X.509 certificates Alistair Francis
2025-02-27 3:09 ` [RFC v2 18/20] lib: rspdm: Support SPDM certificate validation Alistair Francis
2025-02-27 3:09 ` [RFC v2 19/20] rust: allow extracting the buffer from a CString Alistair Francis
2025-02-27 7:52 ` Alice Ryhl
2025-02-27 3:09 ` [RFC v2 20/20] lib: rspdm: Support SPDM challenge Alistair Francis
2025-06-11 13:37 ` [RFC v2 00/20] lib: Rust implementation of SPDM Jonathan Cameron
2025-06-12 5:57 ` Alistair Francis
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=2025022851-usual-backshift-7ea6@gregkh \
--to=gregkh@linuxfoundation.org \
--cc=Jonathan.Cameron@huawei.com \
--cc=a.hindborg@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=alex.gaynor@gmail.com \
--cc=aliceryhl@google.com \
--cc=alistair.francis@wdc.com \
--cc=alistair23@gmail.com \
--cc=alistair@alistair23.me \
--cc=benno.lossin@proton.me \
--cc=bhelgaas@google.com \
--cc=bjorn3_gh@protonmail.com \
--cc=boqun.feng@gmail.com \
--cc=gary@garyguo.net \
--cc=linux-cxl@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=lukas@wunner.de \
--cc=miguel.ojeda.sandonis@gmail.com \
--cc=ojeda@kernel.org \
--cc=rust-for-linux@vger.kernel.org \
--cc=tmgross@umich.edu \
--cc=wilfred.mallawa@wdc.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).