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. ———————————— 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? >> ? >> >> 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/
