Re: Using Rust on non-Rust side of kernel

[Jarkko Sakkinen <jarkko@kernel.org>]

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.

> 
> J.
> 
> -- 
> /-\                             |    It's deja-vu all over again.
> |@/  Debian GNU/Linux Developer |
> \-                              |

BR, Jarkko