Using Rust on non-Rust side of kernel

Using Rust on non-Rust side of kernel

[Jarkko Sakkinen]

Hi

As of today can we possibly do this:

1. drivers/char/tpm (C code)
2. drivers/char/tpm/protocol (imported tpm2_protocol)

?

And then build FFI from C to Rust for building commands that we need
today etc.

There's one particular challenge where this could help: early boot code
for D-RTM (i.e., Trenchboot) as given my crate is just a thing in stack
with no deps, it could be linked also to that payload.

This would be much better integration step for TPM2 than having a
separate driver on Rust side. We could start with tpm2-cmd1/cmd2, then
move on to tpm2-space.c i.e. get all structural processing inside Rust.

tpm2_protocol is light on definitions and should not need any kernel
specific Rust shenanigans.

Consider it as value like integer but just a bit more complex internaal
represention but in the end it is just a value on stack.

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).

BR, Jarkko

Re: Using Rust on non-Rust side of kernel

[Jarkko Sakkinen]

On Sat, Aug 23, 2025 at 03:12:48PM +0300, Jarkko Sakkinen wrote:
> Hi
> 
> As of today can we possibly do this:
> 
> 1. drivers/char/tpm (C code)
> 2. drivers/char/tpm/protocol (imported tpm2_protocol)
> 
> ?
> 
> And then build FFI from C to Rust for building commands that we need
> today etc.
> 
> There's one particular challenge where this could help: early boot code
> for D-RTM (i.e., Trenchboot) as given my crate is just a thing in stack
> with no deps, it could be linked also to that payload.
> 
> This would be much better integration step for TPM2 than having a
> separate driver on Rust side. We could start with tpm2-cmd1/cmd2, then
> move on to tpm2-space.c i.e. get all structural processing inside Rust.
> 
> tpm2_protocol is light on definitions and should not need any kernel
> specific Rust shenanigans.
> 
> Consider it as value like integer but just a bit more complex internaal
> represention but in the end it is just a value on stack.
> 
> 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).
 
The source code since 0.10.0 version has been relocated here:

https://git.kernel.org/pub/scm/linux/kernel/git/jarkko/tpm2-protocol.git

The representation of commands and responses defined is pretty well
high-lighted by

https://bsky.app/profile/jarkk0.bsky.social/post/3lx2n2uvxos2h

I'm also working on a test that measures the estimated compile time
size and realized run-time size (suggested by Philip Tricca) so that
we know where we are at on stack usage.

I've started to optimize it after development phase with some
low-hanging fruit cut already in 0.10.0 but this work is barely
starting [1].

There's also a kselftest compatible test that can be run with
"make test" in the repo using only rustc (build + run circa
2 seconds on my laptop).

[1] https://git.kernel.org/pub/scm/linux/kernel/git/jarkko/tpm2-protocol.git/commit/?id=cd6641bf9e8c8fde8726bece9eb6cdc630d893c2

BR, Jarkko

Re: Using Rust on non-Rust side of kernel

[Jarkko Sakkinen]

Hi,

Would it be possible to response in plain text?

BR, Jarkko

On Sat, Aug 23, 2025 at 11:38:00AM -0300, Daniel Almeida wrote:
> Hi Jarkko,
> 
> I must admit that I had a hard time understanding what you’re trying to say.
> 
> 
>     On 23 Aug 2025, at 09:22, Jarkko Sakkinen <jarkko@kernel.org> wrote:
> 
> 
>     On Sat, Aug 23, 2025 at 03:12:48PM +0300, Jarkko Sakkinen wrote:
> 
>         Hi
> 
>        
> 
>         As of today can we possibly do this:
> 
>        
> 
>         1. drivers/char/tpm (C code)
> 
>         2. drivers/char/tpm/protocol (imported tpm2_protocol)
> 
>        
> 
> 
> What do you mean?
> 
> 
>         ?
> 
>        
> 
>         And then build FFI from C to Rust for building commands that we need
> 
>         today etc.
> 
>        
> 
>         There's one particular challenge where this could help: early boot code
> 
>         for D-RTM (i.e., Trenchboot) as given my crate is just a thing in stack
> 
>         with no deps, it could be linked also to that payload.
> 
>        
> 
>         This would be much better integration step for TPM2 than having a
> 
>         separate driver on Rust side. We could start with tpm2-cmd1/cmd2, then
> 
>         move on to tpm2-space.c i.e. get all structural processing inside Rust.
> 
> 
> Can you expand on what these cmds are?
> 
> 
>        
> 
>         tpm2_protocol is light on definitions and should not need any kernel
> 
>         specific Rust shenanigans.
> 
> 
> You mean the Rust abstractions?
> 
> 
>        
> 
>         Consider it as value like integer but just a bit more complex internaal
> 
>         represention but in the end it is just a value on stack.
> 
> 
> Not sure what you mean here either.
> 
> 
>        
> 
>         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).
> 
>    
>     The source code since 0.10.0 version has been relocated here:
>    
>     https://git.kernel.org/pub/scm/linux/kernel/git/jarkko/tpm2-protocol.git
>    
>     The representation of commands and responses defined is pretty well
>     high-lighted by
>    
>     https://bsky.app/profile/jarkk0.bsky.social/post/3lx2n2uvxos2h
>    
>     I'm also working on a test that measures the estimated compile time
>     size and realized run-time size (suggested by Philip Tricca) so that
>     we know where we are at on stack usage.
>    
>     I've started to optimize it after development phase with some
>     low-hanging fruit cut already in 0.10.0 but this work is barely
>     starting [1].
>    
>     There's also a kselftest compatible test that can be run with
>     "make test" in the repo using only rustc (build + run circa
>     2 seconds on my laptop).
>    
>     [1] https://git.kernel.org/pub/scm/linux/kernel/git/jarkko/
>     tpm2-protocol.git/commit/?id=cd6641bf9e8c8fde8726bece9eb6cdc630d893c2
>    
>     BR, Jarkko
> 
> 
> 
> 
> My somewhat limited understanding here is that you’re trying to implement Rust
> code that can be called from the rest of the kernel, but that otherwise doesn’t
> depend on it? 
> 
> 
> If so, I did try something similar [0]. Perhaps this is useful to you and is
> somewhat applicable to your use case as well?
> 
> [0]: https://lwn.net/Articles/970565/
> 
> 

Re: Using Rust on non-Rust side of kernel

[Jarkko Sakkinen]

On Sun, Aug 24, 2025 at 02:06:24AM +0300, Jarkko Sakkinen wrote:
> Hi,
> 
> Would it be possible to response in plain text?

Is highlighted at lore [1]:

"[not found]   <BE42A51A-60C4-4E79-8459-CADEAB8DC3BA@collabora.com>"

Also it is quite cluttered to read your response in mutt, as you can
probably see from my earlier response :-)

Not disregarding the response but it is right now quite convoluted.

See [2] for more information.

[1] https://lore.kernel.org/rust-for-linux/aKpJbIEZss_l-8wb@kernel.org/T/#t
[2] https://www.kernel.org/doc/html/latest/process/email-clients.html

BR, Jarkko

Re: Using Rust on non-Rust side of kernel

[Daniel Almeida]

Hi Jarkko,

> On 23 Aug 2025, at 20:12, Jarkko Sakkinen <jarkko@kernel.org> wrote:
> 
> On Sun, Aug 24, 2025 at 02:06:24AM +0300, Jarkko Sakkinen wrote:
>> Hi,
>> 
>> Would it be possible to response in plain text?
> 
> Is highlighted at lore [1]:
> 
> "[not found]   <BE42A51A-60C4-4E79-8459-CADEAB8DC3BA@collabora.com>"
> 
> Also it is quite cluttered to read your response in mutt, as you can
> probably see from my earlier response :-)
> 
> Not disregarding the response but it is right now quite convoluted.
> 
> See [2] for more information.
> 
> [1] https://lore.kernel.org/rust-for-linux/aKpJbIEZss_l-8wb@kernel.org/T/#t
> [2] https://www.kernel.org/doc/html/latest/process/email-clients.html
> 
> BR, Jarkko

Sorry. Yeah I am aware of plain-text, but I was on the go and turns out that my
phone is not properly configured. Let me copy-and-paste this here so we have
the full context and also so that it shows up in lore.

I didn't have the time to read your response by the way, but I will get back to
you in the next couple of days.


————————————


Hi Jarkko,

I must admit that I had a hard time understanding what you’re trying to say.

> On 23 Aug 2025, at 09:22, Jarkko Sakkinen <jarkko@kernel.org> wrote:
> 
> On Sat, Aug 23, 2025 at 03:12:48PM +0300, Jarkko Sakkinen wrote:
>> Hi
>> 
>> As of today can we possibly do this:
>> 
>> 1. drivers/char/tpm (C code)
>> 2. drivers/char/tpm/protocol (imported tpm2_protocol)
>> 

What do you mean?

>> ?
>> 
>> And then build FFI from C to Rust for building commands that we need
>> today etc.
>> 
>> There's one particular challenge where this could help: early boot code
>> for D-RTM (i.e., Trenchboot) as given my crate is just a thing in stack
>> with no deps, it could be linked also to that payload.
>> 
>> This would be much better integration step for TPM2 than having a
>> separate driver on Rust side. We could start with tpm2-cmd1/cmd2, then
>> move on to tpm2-space.c i.e. get all structural processing inside Rust.

Can you expand on what these cmds are?

>> 
>> tpm2_protocol is light on definitions and should not need any kernel
>> specific Rust shenanigans.

You mean the Rust abstractions?

>> 
>> Consider it as value like integer but just a bit more complex internaal
>> represention but in the end it is just a value on stack.

Not sure what you mean here either.

>> 
>> 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).
> 
> The source code since 0.10.0 version has been relocated here:
> 
> https://git.kernel.org/pub/scm/linux/kernel/git/jarkko/tpm2-protocol.git
> 
> The representation of commands and responses defined is pretty well
> high-lighted by
> 
> https://bsky.app/profile/jarkk0.bsky.social/post/3lx2n2uvxos2h
> 
> I'm also working on a test that measures the estimated compile time
> size and realized run-time size (suggested by Philip Tricca) so that
> we know where we are at on stack usage.
> 
> I've started to optimize it after development phase with some
> low-hanging fruit cut already in 0.10.0 but this work is barely
> starting [1].
> 
> There's also a kselftest compatible test that can be run with
> "make test" in the repo using only rustc (build + run circa
> 2 seconds on my laptop).
> 
> [1] https://git.kernel.org/pub/scm/linux/kernel/git/jarkko/tpm2-protocol.git/commit/?id=cd6641bf9e8c8fde8726bece9eb6cdc630d893c2
> 
> BR, Jarkko



My somewhat limited understanding here is that you’re trying to implement
Rust code that can be called from the rest of the kernel, but that otherwise
doesn’t depend on it?  

If so, I did try something similar [0]. Perhaps this is useful to you and is
somewhat applicable to your use case as well?

[0]: https://lwn.net/Articles/970565/

Re: Using Rust on non-Rust side of kernel

[Jarkko Sakkinen]

On Sat, Aug 23, 2025 at 10:12:44PM -0300, Daniel Almeida wrote:
> Hi Jarkko,
> 
> > On 23 Aug 2025, at 20:12, Jarkko Sakkinen <jarkko@kernel.org> wrote:
> > 
> > On Sun, Aug 24, 2025 at 02:06:24AM +0300, Jarkko Sakkinen wrote:
> >> Hi,
> >> 
> >> Would it be possible to response in plain text?
> > 
> > Is highlighted at lore [1]:
> > 
> > "[not found]   <BE42A51A-60C4-4E79-8459-CADEAB8DC3BA@collabora.com>"
> > 
> > Also it is quite cluttered to read your response in mutt, as you can
> > probably see from my earlier response :-)
> > 
> > Not disregarding the response but it is right now quite convoluted.
> > 
> > See [2] for more information.
> > 
> > [1] https://lore.kernel.org/rust-for-linux/aKpJbIEZss_l-8wb@kernel.org/T/#t
> > [2] https://www.kernel.org/doc/html/latest/process/email-clients.html
> > 
> > BR, Jarkko
> 
> Sorry. Yeah I am aware of plain-text, but I was on the go and turns out that my
> phone is not properly configured. Let me copy-and-paste this here so we have
> the full context and also so that it shows up in lore.
> 
> I didn't have the time to read your response by the way, but I will get back to
> you in the next couple of days.

NP :-) 


> 
> 
> ————————————
> 
> 
> Hi Jarkko,
> 
> I must admit that I had a hard time understanding what you’re trying to say.
> 
> > On 23 Aug 2025, at 09:22, Jarkko Sakkinen <jarkko@kernel.org> wrote:
> > 
> > On Sat, Aug 23, 2025 at 03:12:48PM +0300, Jarkko Sakkinen wrote:
> >> Hi
> >> 
> >> As of today can we possibly do this:
> >> 
> >> 1. drivers/char/tpm (C code)
> >> 2. drivers/char/tpm/protocol (imported tpm2_protocol)
> >> 
> 
> What do you mean?

OK, I'm scavenging the options more than driving any plan. As can be
seen from this Makefile the code is somewhat isolated:

https://git.kernel.org/pub/scm/linux/kernel/git/jarkko/tpm2-protocol.git/tree/Makefile

It's also fully mmless with the goal of providing TPM protocol for
early boot code even at the point of time when memory is not fully
configured.

In the pre-existing driver case I'm wondering is it so that you either
have a Rust driver or C driver or can I have a C driver that has a
"Rust engine" for doing structured analysis?

Not sure if that would work in the generic case (e.g. for something
that would use alloc) but my implementation is even more constrained
than typical Rust kernel code. It really does not require anything
from its surroundings.

It has recursively constrained limits and I'm actually now doing
research if I could demo it inside eBPF filter :-) I'm not sure
tho is eBPF rustc capable of doing necessary unrolls. I have
recursively in all levels static limits to everything.

My goal at the moment is to get this into TPM-RS and this is more
like initial research. And also, I'm also rising awareness my work
so that if there was someone working on e.g., Rust TPM2 driver,
I think it'd be a great idea to combine that work with this
code.

Partly I initiated this work as a result of seeing all these nasty
fights over C vs Rust code. I thought that this like a great
contribution from my side to linux-rust and someone more seasoned
with that side can take advantage of my 11 years domain expertise
with TPM2 protocol. I.e. I'm trying to driver collaboration instead
of conflict :-)

The idea for ACPICA alike import policy where multiple projects
share same protocol assets comes from the observation that it is
a complicated protocol in its own right so we are better off fixing
that stuff in a single location. I.e. fixing TPM-RS would then
benefit also kernel.

I think I've really nailed the realization of it in software and
this has been the key issue with TPM2 for over a decade.

Partially some product categories exist because there is no real
developer experience for TPM2, which is very capable cryptographic
entity.

E.g., you could easily replace Yubikeys and similar products with
TPM2, and that type of products exist are merely a consequence
of the worst developer experience ever.

To replace Yubikey, you would need a cloud service that would
move secrets as you change your machine. It can be done without
surveillance. And given that this can easily wrap some other
keystore with TPM2 appearance, you could e.g. include the
whole Android ecosystem to that kind of scheme (this is what
I've been saying to Google employees I've talked with).

> 
> >> ?
> >> 
> >> And then build FFI from C to Rust for building commands that we need
> >> today etc.
> >> 
> >> There's one particular challenge where this could help: early boot code
> >> for D-RTM (i.e., Trenchboot) as given my crate is just a thing in stack
> >> with no deps, it could be linked also to that payload.
> >> 
> >> This would be much better integration step for TPM2 than having a
> >> separate driver on Rust side. We could start with tpm2-cmd1/cmd2, then
> >> move on to tpm2-space.c i.e. get all structural processing inside Rust.
> 
> Can you expand on what these cmds are?

Sure. See commands spec from

https://trustedcomputinggroup.org/resource/tpm-library-specification/

> 
> >> 
> >> tpm2_protocol is light on definitions and should not need any kernel
> >> specific Rust shenanigans.
> 
> You mean the Rust abstractions?

Yep.

> 
> >> 
> >> Consider it as value like integer but just a bit more complex internaal
> >> represention but in the end it is just a value on stack.
> 
> Not sure what you mean here either.

It does not need mm. all marshalling and unmarshalling of the protocol
can be done in-stack. You can of course box it and it is also fully
dyn-compatible while being decoupled from that as proved by a test
case a called "test_dynamic_roundtrip_blind_parse":

https://git.kernel.org/pub/scm/linux/kernel/git/jarkko/tpm2-protocol.git/tree/tests/runner.rs

> 
> >> 
> >> 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).
> > 
> > The source code since 0.10.0 version has been relocated here:
> > 
> > https://git.kernel.org/pub/scm/linux/kernel/git/jarkko/tpm2-protocol.git
> > 
> > The representation of commands and responses defined is pretty well
> > high-lighted by
> > 
> > https://bsky.app/profile/jarkk0.bsky.social/post/3lx2n2uvxos2h
> > 
> > I'm also working on a test that measures the estimated compile time
> > size and realized run-time size (suggested by Philip Tricca) so that
> > we know where we are at on stack usage.
> > 
> > I've started to optimize it after development phase with some
> > low-hanging fruit cut already in 0.10.0 but this work is barely
> > starting [1].
> > 
> > There's also a kselftest compatible test that can be run with
> > "make test" in the repo using only rustc (build + run circa
> > 2 seconds on my laptop).
> > 
> > [1] https://git.kernel.org/pub/scm/linux/kernel/git/jarkko/tpm2-protocol.git/commit/?id=cd6641bf9e8c8fde8726bece9eb6cdc630d893c2
> > 
> > BR, Jarkko
> 
> 
> 
> My somewhat limited understanding here is that you’re trying to implement
> Rust code that can be called from the rest of the kernel, but that otherwise
> doesn’t depend on it?  
> 
> If so, I did try something similar [0]. Perhaps this is useful to you and is
> somewhat applicable to your use case as well?
> 
> [0]: https://lwn.net/Articles/970565/

I will do research on this! This is really just early research. I think
eventually fully migrating TPM driver Rust would make sense as we could
then do e.g., much more capable /dev/tpmrm0 than we can do today but
it would be nice to have some "intermediate steps" in-between.

BR, Jarkko

Re: Using Rust on non-Rust side of kernel

[Jarkko Sakkinen]

On Sun, Aug 24, 2025 at 10:15:37AM +0300, Jarkko Sakkinen wrote:
> > >> There's one particular challenge where this could help: early boot code
> > >> for D-RTM (i.e., Trenchboot) as given my crate is just a thing in stack
> > >> with no deps, it could be linked also to that payload.

Right so if anyone working on Trenchboot (which I'm helping with by
giving feedback on implementation strategy) is raising eyebrows,
fear not ...

It's more about that if redoing any TPM stuff in Rust, it's best
to design as much of it as possible to run bare metal rather than
requiring a kernel, and only leave small slice of IO code to be
integrated to Linux APIs.

I.e. make a design that addresses all the bottlenecks we've seen
over the years... Thus, tpm2-protocol was first designed with
bare metal in mind, and secondly kernel.

BR, Jarkko

Re: Using Rust on non-Rust side of kernel

[Jarkko Sakkinen]

On Sat, Aug 23, 2025 at 11:38:00AM -0300, Daniel Almeida wrote:
> My somewhat limited understanding here is that you’re trying to implement Rust
> code that can be called from the rest of the kernel, but that otherwise doesn’t
> depend on it? 

OK so please fill me up with rest of the email I'll respond to this
uncluttered part.

First of all, it's fully TCG spec complete in-stack implementation
with no dependencies, does not use allocator, no_std all implementation,
which can run even on bare metal and could empower chips. tpm2_protocol
generates bidirectional parsers and builders to both directions.

It purposely does not share anything with the environment.

The gist here is that given the implementations of properties this could
be used as shared entity between kernel and TPM-RS project, which would
give a single shared project, which would be anyhow "same same" if they
had separate implementations.

Not being dependent on kernel code would make it also applicable to
early boot code because you can put it anywhere, or link against
anything. E.g., perhaps Trechnboot could be one of such use case
because for that we need to find model where protocol is needed
without having TPM driver in the first place.

For TPM driver itself it would increase stability because the crate
gives guarantees on structural integrity vs looking at just "max
length".
> 
> 
> If so, I did try something similar [0]. Perhaps this is useful to you and is
> somewhat applicable to your use case as well?

Thanks! I will look into this :-)  I'm not like pushing anything
this just early querying what are options for the future. I.e is
Rust code enforced live its own cage or are there options for
doing "hybrid solutions". I'm only starting to learn of the 
possible integration options. I.e. not even debating of anything,
only learning.

> 
> [0]: https://lwn.net/Articles/970565/
> 
> 

BR, Jarkko

Re: Using Rust on non-Rust side of kernel

[Jarkko Sakkinen]

On Sun, Aug 24, 2025 at 02:41:06AM +0300, Jarkko Sakkinen wrote:
> doing "hybrid solutions". I'm only starting to learn of the 
> possible integration options. I.e. not even debating of anything,
> only learning.

I.e. I don't know what I'm doing, thus asking random questions :-)

I do know however that my implementation is somewhat solid piece of code
and with high odds best available implementation of TPM2 protocol
marshalling and unmarshalling, at least as per core architecture (needs
obviously still maturization, I wrote it all in three weeks).

It's also complex enough problem (as people have done somewhat unsuccessful
attempts for past decaede) that we don't want to solve it twice (i.e.
for TPM-RS and kernel). It's fully isolated from the context.

I've also talked with some companies and people working on e.g. keystores,
and they've fully grabbed the idea how something like this can be used
as interop layer (i.e. a keystore acting TPM2), which further supports
an import model for this code (while it can be installed through cargo
too).

It coverages TCG version 184 specs and my idea is that with a new vger
list future spec updates could be managed in controlled fashion, and
we can build a process for imports.

BR, Jarkko

Re: Using Rust on non-Rust side of kernel

[Jonathan McDowell]

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.

(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.)

J.

-- 
/-\                             |    It's deja-vu all over again.
|@/  Debian GNU/Linux Developer |
\-                              |

Re: Using Rust on non-Rust side of kernel

[Jarkko Sakkinen]

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

Re: Using Rust on non-Rust side of kernel

[Jarkko Sakkinen]

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

Re: Using Rust on non-Rust side of kernel

[Jarkko Sakkinen]

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_UPRB@kernel.org/T/#u

BR, Jarkko

Re: Using Rust on non-Rust side of kernel

[Jarkko Sakkinen]

On Tue, Aug 26, 2025 at 01:29:59AM +0300, Jarkko Sakkinen wrote:
> 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.

Considering existing TPM C driver, Linux keyring (from trusted keys
angle and likely in future from imported asymmetric keys angle) and
security stuff overall in kernel, this work really can fuel up both
developer and debuging experience. I.e. my motivation is really 180
degrees opposite than deleting anything :-) [maybe that's why I got a
bit upset]

And doing tools like tpmtrace will quickly level up the feasibility in
production through stress testing in the field. And as I improve tpm2sh
(which I don't yet recommend anyone to use, it's so far just quickly
upgraded to test the protocol changes, I'm now stabilizing it ) we can
better evaluate different choices given better toolkit that will
consequently reduce the number of wrong decisions.

Like in pretty basic kernel testing it's not too feasible to package
something tpm2-tools to an image that you build (I do full rootfs
per kernel patch when testing) but something like tpm2sh and in
future tpmtrace are much more nicer blobs given how rust ELF images
are constructed and linked. Downscaling of the stack  has been 
a QA issue for ages now.

BR, Jarkko

Re: Using Rust on non-Rust side of kernel

[Jonathan McDowell]

(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

Re: Using Rust on non-Rust side of kernel

[Jarkko Sakkinen]

On Tue, Aug 26, 2025 at 09:35:08AM +0100, Jonathan McDowell wrote:
> 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 think we're in the same line here really :-) And apologies for
over-reacting, I definitely went over the top!

I did the marshaller/unmarshaller exactly for Rust TPM driver only in
the sense that if I got a patch set on my table doing that, it would be
the part which is complex enough that I would actually be in trouble.
So consider it like "years ahead preparation".

I quickly went through your list as a reality check if I have blind
spot but for the most part it is "business as usual" type of stuff,
some to change done many years ago (at least as old as tpmrm0).

Obvious exception to the rule are bugs related to HMAC encryption
to which I think we have now a resolution.

BR, Jarkko

Re: Using Rust on non-Rust side of kernel

[Jarkko Sakkinen]

On Tue, Aug 26, 2025 at 11:56:48AM +0300, Jarkko Sakkinen wrote:
> On Tue, Aug 26, 2025 at 09:35:08AM +0100, Jonathan McDowell wrote:
> > 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 think we're in the same line here really :-) And apologies for
> over-reacting, I definitely went over the top!
> 
> I did the marshaller/unmarshaller exactly for Rust TPM driver only in
> the sense that if I got a patch set on my table doing that, it would be
> the part which is complex enough that I would actually be in trouble.
> So consider it like "years ahead preparation".

As per having e.g. C driver with some Rust in and all sort of ways to
integrate Rust code etc. I definitely want to experiment with that type
of stuff in experimental branches. It's single best way to learn stuff
to do integrations (factors better than "how to program") at least for
me. Kernel dev is all about how sandboxes are created and not so
much how to program kernel (IMHO).

> 
> I quickly went through your list as a reality check if I have blind
> spot but for the most part it is "business as usual" type of stuff,
> some to change done many years ago (at least as old as tpmrm0).
> 
> Obvious exception to the rule are bugs related to HMAC encryption
> to which I think we have now a resolution.
> 
> BR, Jarkko
> 

BR, Jarkko