Re: Using Rust on non-Rust side of kernel

[Jonathan McDowell <noodles@earth.li>]

(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