On Sat, Aug 23, 2025 at 10:12:44PM -0300, Daniel Almeida wrote: > Hi Jarkko, > > > On 23 Aug 2025, at 20:12, Jarkko Sakkinen <jar...@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-cadeab8dc...@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-...@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 <jar...@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
