(I've seen your later mails, but I think this is the right one for me to
respond to around what my concerns are.)
On Mon, Aug 25, 2025 at 10:30:23PM +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*.
I'm not saying we shouldn't prepare for future outcomes. It sounds like
you're focusing on the marshalling/unmarshalling piece with Rust, rather
than expecting to replace the entire of drivers/char/tpm/ so that
worries me less.
(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.
I think you're confusing my concerns with concerns others have about
/dev/tpmrm0. I'm not overly worried about that. I suspect there might be
some cleanups that can be done, but we use it as our resource broker and
I don't believe it to be the root cause of any of the issues we have
seen.
If you're focused on marshalling + unmarshalling then I don't recall
seeing issues there. What I'm thinking of more are the workarounds for
firmware issues, or the subtle timing bugs that have sat in the kernel
for a number of revisions before they've been tracked down and resolved.
I'm not intending to be obnoxious; these are not fundamental design
issues, just code fixes that have hardened the driver over time. If we
were talking about ripping everything out then my concern would be we'd
have to do all this battle hardening over again, no matter what our best
efforts. i.e. we've already done some work fixing the inconsistencies,
let's make sure we don't lose that.
Examples of the sorts of fixes I'm thinking about:
d4640c394f23 tpm: Check for completion after timeout
2f661f71fda1 tpm: tis: Double the timeout B to 4s
1dbf74e00a5f tpm: End any active auth session before shutdown
de9e33df7762 tpm, tpm_tis: Workaround failed command reception on Infineon
devices
7146dffa875c tpm, tpm_tis: Fix timeout handling when waiting for TPM status
e3aaebcbb7c6 tpm: Clean up TPM space after command failure
(I've also got another issue I'm currently trying to work through but
I'm pretty sure it's a firmware bug and until I nail it down fully with
a reproducible test I can't determine if there's a suitable kernel
workaround, or it _needs_ a firmware upgrade.)
J.
--
Web [ 101 things you can't have too much of : 22 - Friends. ]
site: https:// [ ] Made by
www.earth.li/~noodles/ [ ] HuggieTag 0.0.24
