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
