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. BR, Jarkko
