Re: Using Rust on non-Rust side of kernel

[Jarkko Sakkinen <jarkko@kernel.org>]

On Mon, Aug 25, 2025 at 10:42:45PM +0300, Jarkko Sakkinen wrote:
> On Mon, Aug 25, 2025 at 10:30:27PM +0300, Jarkko Sakkinen wrote:
> > On Mon, Aug 25, 2025 at 01:04:38PM +0100, Jonathan McDowell wrote:
> > > On Sat, Aug 23, 2025 at 03:12:44PM +0300, Jarkko Sakkinen wrote:
> > > 
> > > > My goal with tpm2_protocol is to have ACPICA alike model of imports as
> > > > the crate is driven by TCG spec updates and it is very likely to be
> > > > also used by TPM-RS (also via import style process).
> > > 
> > > I'm not entirely clear on what your plan is for this / the existing TPM
> > > drivers in the kernel? I assume it's to eventually remove some of the C code
> > > in favour of the Rust implementation, but I'm missing exactly how that's
> > > expected to work.
> > 
> > There's no plan of doing anything at this point. This is more like doing
> > early research for the following questions:
> > 
> > 1. If this comes up in form or another, what are the directions of freedom.
> > 2. What could be in general done in Rust that could potentially extend
> >    the capabilities of e.g. /dev/tpmrm0 (which could be entirely
> >    different device).
> > 3. There has not been any discussion from my part of removing and/or
> >    repealing and replacing any of the C driver code.
> > 
> > It's a bit odd position IMHO to not prepare for future outcomes. Even
> > without kernel context, for the TPM marshalling/unmarshalling there does
> > not exist decent implementation as of today in *any language*.
> > 
> > There's been way too many unprepared situations of C-to-Rust
> > transformations, and learning lessons from that, I think it was the
> > priority to implement the protocol part so that it has enough time to
> > mature when the day might come.
> > 
> > > 
> > > (Given I've spent a bunch of time this year tracking down various edge case
> > > issues in the TPM code that have been causing failures in our fleet I'm
> > > understandably wary of a replacement of the core code. *It* might be a
> > > perfect spec implementation, but hardware rarely is.)
> > 
> > I think this is somewhat unconstructive comment. How do you implement
> > against anything if you don't follow the spec and later on fix the
> > incosistencies?
> > 
> > I have not observed high stream of marshalling and unmarshalling
> > associated bugs or other issues.
> > 
> > Also if you make obnoxious arguments like that please also underline
> > how implementation A is worse at dealing possible inconsistencies
> > than implementation B. Otherwise, you're only spreading FUD.
> 
> My claim is that more high granularity marshaller and unmarshaller is
> actually better at both catching and scoping incosistencies, and thus
> it speeds up resolving bugs in that code and/or create workaround and
> quirks. What is your argument?
> 
> My pure guess is that the comment was that Google's device does not have
> TPM2_ContextSave. How that does trip marshaller and/or unmarshaller
> if a command or response does not exist?
> 
> This goes beyond the topic but I want again underline that:
> 
> 1. /dev/tpmrm0 has existed since 2017.
> 2. Is used by many tools, such as systemd.
> 3. Google has failed so far to provide a change (within almost
>    nine year time period) to Linux kernel that would
>    disable /dev/tpmrm0 to any of their hardware.

I'm sorry Jonathan could have been a more polite tone but at least this
addresses your main concern: no absolutely not I'm pushing any type of
Rust driver :-) And I fully understand why someone might get a picture
that I had that type of thoughts.

I am going to most likely make experiments with kernel and most
definitely make "tpmtrace" (a tool that hooks to BPF ring buffer and
pretty prints the protocol in real-time, it's dead easy to do now).
Finally (as I've said before) it would be quite unproductive to create a
design that does not upscale to let's say to an attestation server
(which would use this to parse e.g. quotes) or downscale to a chip.

Other than that it's open for patches and from my side I'm ready to
review and apply patches and maintain stable branches once 0.11.0
is out [1].

[1] https://lore.kernel.org/tpm2/aKzaTYCI2GO_UPRB@kernel.org/T/#u

BR, Jarkko