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_u...@kernel.org/T/#u BR, Jarkko
