Using Rust on non-Rust side of kernel
Subsystems (2)
Jarkko Sakkinen
maintainerHi
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
Jarkko Sakkinen
maintainerQuoted 23 lines · Jarkko Sakkinen
Hi
As of today can we possibly do this:
1.
drivers/char/tpm(C code)
2.drivers/char/tpm/protocol(importedtpm2_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.ci.e. get all structural processing inside Rust.
tpm2_protocolis light on definitions and should not need any kernel specific Rust shenanigans.
Quoted 6 lines
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_protocolis 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).
BR, Jarkko
Jarkko Sakkinen
maintainerHi,
Would it be possible to response in plain text?
BR, Jarkko
Quoted 125 lines · Daniel Almeida
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 <[email protected]> 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(importedtpm2_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.ci.e. get all structural processing inside Rust.Can you expand on what these cmds are?
tpm2_protocolis light on definitions and should not need any kernelspecific 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_protocolis to have ACPICA alike model of imports asthe 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=cd6641bf9e8c8fde8726bece9eb6cdc630d893c2BR, 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?
Jarkko Sakkinen
maintainerQuoted 3 lines · Jarkko Sakkinen
Hi,
Would it be possible to response in plain text?
Is highlighted at lore [1]:
"[not found] <[email protected]>"
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/[email protected]/T/#t
[2] https://www.kernel.org/doc/html/latest/process/email-clients.html
BR, Jarkko
Jarkko Sakkinen
maintainerQuoted 3 lines · Daniel Almeida
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".
Quoted 4 lines
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.
Quoted 4 lines
BR, Jarkko
Jarkko Sakkinen
maintainerQuoted 3 lines · Jarkko Sakkinen
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
Daniel Almeida
reviewerHi Jarkko,
Quoted 14 lines · Jarkko Sakkinen
Quoted 3 lines · Jarkko Sakkinen
Hi,
Would it be possible to response in plain text?
Is highlighted at lore [1]:
"[not found] <[email protected]>"
Also it is quite cluttered to read your response in mutt, as you can probably see from my earlier response :-)
Quoted 8 lines
Not disregarding the response but it is right now quite convoluted.
See [2] for more information.
[1] https://lore.kernel.org/rust-for-linux/[email protected]/T/#t
[2] https://www.kernel.org/doc/html/latest/process/email-clients.htmlBR, 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.
Quoted 10 lines · Jarkko Sakkinen
Quoted 7 lines · Jarkko Sakkinen
Hi
As of today can we possibly do this:
1.
drivers/char/tpm(C code)
2.drivers/char/tpm/protocol(importedtpm2_protocol)
What do you mean?
Quoted 5 lines
Quoted 5 lines
?
And then build FFI from C to Rust for building commands that we need today etc.
Quoted 7 lines
Quoted 7 lines
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.ci.e. get all structural processing inside Rust.
Can you expand on what these cmds are?
Quoted 3 lines
Quoted 3 lines
tpm2_protocolis light on definitions and should not need any kernel specific Rust shenanigans.
You mean the Rust abstractions?
Quoted 3 lines
Quoted 3 lines
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.
Quoted 22 lines
Quoted 4 lines
My goal with
tpm2_protocolis 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].
Quoted 7 lines
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).
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?
Jarkko Sakkinen
maintainerQuoted 23 lines · Daniel Almeida
Hi Jarkko,
Quoted 21 lines · Jarkko Sakkinen
Quoted 3 lines · Jarkko Sakkinen
Hi,
Would it be possible to response in plain text?
Is highlighted at lore [1]:
"[not found] <[email protected]>"
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/[email protected]/T/#t
[2] https://www.kernel.org/doc/html/latest/process/email-clients.html
Quoted 8 lines
Quoted 1 line
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 :-)
Quoted 14 lines
————————————
Hi Jarkko,
I must admit that I had a hard time understanding what you’re trying to say.
Quoted 5 lines · Jarkko Sakkinen
Quoted 2 lines · Jarkko Sakkinen
Hi
Quoted 7 lines
Quoted 5 lines
Quoted 5 lines
As of today can we possibly do this:
1.
drivers/char/tpm(C code)
2.drivers/char/tpm/protocol(importedtpm2_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).
Quoted 10 lines
Quoted 10 lines
Quoted 10 lines
?
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.
Quoted 5 lines
Quoted 3 lines
Quoted 3 lines
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.ci.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/
Quoted 6 lines
Quoted 4 lines
Quoted 4 lines
tpm2_protocolis light on definitions and should not need any kernel specific Rust shenanigans.You mean the Rust abstractions?
Yep.
Quoted 6 lines
Quoted 4 lines
Quoted 4 lines
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
Quoted 33 lines
Quoted 23 lines
Quoted 5 lines
My goal with
tpm2_protocolis 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].
Quoted 7 lines
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).
BR, Jarkko
Quoted 8 lines
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?
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
Jarkko Sakkinen
maintainerQuoted 3 lines · Jarkko Sakkinen
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
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
Quoted 3 lines · Jarkko Sakkinen
My goal with
tpm2_protocolis 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.
Signature · 3 lines
/-\ | It's deja-vu all over again. |@/ Debian GNU/Linux Developer | \- |
Jarkko Sakkinen
maintainerQuoted 10 lines · Jonathan McDowell
Quoted 3 lines · Jarkko Sakkinen
My goal with
tpm2_protocolis 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.
Quoted 5 lines
(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.
Quoted 7 lines
J.
Signature · 3 lines
/-\ | It's deja-vu all over again. |@/ Debian GNU/Linux Developer | \- |
BR, Jarkko
Jarkko Sakkinen
maintainerQuoted 41 lines · Jarkko Sakkinen
Quoted 10 lines · Jonathan McDowell
Quoted 3 lines · Jarkko Sakkinen
My goal with
tpm2_protocolis 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.
Quoted 5 lines
(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?
Quoted 6 lines
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
Jarkko Sakkinen
maintainerQuoted 58 lines · Jarkko Sakkinen
Quoted 41 lines · Jarkko Sakkinen
Quoted 10 lines · Jonathan McDowell
Quoted 3 lines · Jarkko Sakkinen
My goal with
tpm2_protocolis 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.
Quoted 5 lines
(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?
Quoted 6 lines
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?
Quoted 7 lines
This goes beyond the topic but I want again underline that:
1.
/dev/tpmrm0has 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/tpmrm0to 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/[email protected]/T/#u
BR, Jarkko
Jarkko Sakkinen
maintainerQuoted 6 lines · Jarkko Sakkinen
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
(I've seen your later mails, but I think this is the right one for me to respond to around what my concerns are.)
Quoted 22 lines · Jarkko Sakkinen
Quoted 10 lines · Jonathan McDowell
Quoted 3 lines · Jarkko Sakkinen
My goal with
tpm2_protocolis 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.
Quoted 3 lines
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.
Quoted 9 lines
Quoted 4 lines
(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?
Quoted 6 lines
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 timeout2f661f71fda1 tpm: tis: Double the timeout B to 4s1dbf74e00a5f 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.
Signature · 3 lines
Web [ 101 things you can't have too much of : 22 - Friends. ] site: https:// [ ] Made by www.earth.li/~noodles/ [ ] HuggieTag 0.0.24
Jarkko Sakkinen
maintainerQuoted 6 lines · Jonathan McDowell
d4640c394f23tpm: Check for completion after timeout2f661f71fda1tpm: tis: Double the timeout B to 4s1dbf74e00a5ftpm: End any active auth session before shutdownde9e33df7762tpm,tpm_tis: Workaround failed command reception on Infineon devices7146dffa875ctpm,tpm_tis: Fix timeout handling when waiting for TPM statuse3aaebcbb7c6tpm: 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
Jarkko Sakkinen
maintainerQuoted 8 lines · Jarkko Sakkinen
Quoted 6 lines · Jonathan McDowell
d4640c394f23tpm: Check for completion after timeout2f661f71fda1tpm: tis: Double the timeout B to 4s1dbf74e00a5ftpm: End any active auth session before shutdownde9e33df7762tpm,tpm_tis: Workaround failed command reception on Infineon devices7146dffa875ctpm,tpm_tis: Fix timeout handling when waiting for TPM statuse3aaebcbb7c6tpm: Clean up TPM space after command failure
Quoted 7 lines
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).
Quoted 10 lines
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