All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jarkko Sakkinen <jarkko@kernel.org>
To: tpm2@lists.linux.dev, linux-integrity@vger.kernel.org
Cc: Jason Gunthorpe <jgg@ziepe.ca>,
	Josh Triplett <josh@joshtriplett.org>,
	rust-for-linux@vger.kernel.org
Subject: Re: tpm2_protocol/tpm2sh
Date: Thu, 14 Aug 2025 07:28:43 +0300	[thread overview]
Message-ID: <aJ1l-xZ6-UlIsX0L@kernel.org> (raw)
In-Reply-To: <aJ1kNzDf-9r_16Cs@kernel.org>

On Thu, Aug 14, 2025 at 07:21:15AM +0300, Jarkko Sakkinen wrote:
> Hi,
> 
> Crates for 0.5.4:
> 
> https://crates.io/crates/tpm2_protocol
> https://crates.io/crates/tpm2sh
> 
> As I said earlier tpm2_protocol is no_std, zero 3rd party dependence
> crate that does not require a memory allocator, and its first priority
> driver for design choices has been Linux kernel. However, given the
> design, it could even power the actual chip itself orchestrated by a
> microcontroller.
> 
> It's unipolar TPM 2.0 protocol implementation, which can power anything
> from to actual chips given ability to build and parse both commands and
> responsese.
> 
> This mean in English that if you take e.g., a command byte stream, parse
> it and feed that to the builder you will get the exact same bytestream.
> The same principle applies responses.
> 
> For upcoming release the rest of the work is basically just populate
> rest of the TCG spec, which is easy given the declarative domain
> language designed with `macro_rules!` construct.
> 
> "A demo video":
> 
> https://social.kernel.org/notice/Ax9FRqKTBL69UYMIW8
> 
> Some things we could do given someone has some driver to do so, which
> we could not realistically do with the pre-existing C driver:
> 
> 1. Super high-granularity configurable resource manager (perhaps with
>    eBPF filtering)
> 2. Kernel driven vTPMs (as it is bidirectional).
> 3. Perhaps even offer vTPM implementations also for CoC VMs.
> 4. Not in kernel necessarily but if you have a keystore/crypto product
>    you can use it for building interoperability layer.
> 5. Given extremely sophisticated building/parsing capabilities,
>    implementing e.g., a tailord remote attestation server becomes super
>    easy, given that server can use it (w/o TPM ofc) to to carve the data it
>    wants from the protocol shenanigans.
> 
> Can rarely say this but it's the first ever unipolar and across the
> board role agnostic TPM2 protocol implementation - first of its kind
> :-)

****

BR, Jarkko

      reply	other threads:[~2025-08-14  4:28 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-08-14  4:21 tpm2_protocol/tpm2sh Jarkko Sakkinen
2025-08-14  4:28 ` Jarkko Sakkinen [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=aJ1l-xZ6-UlIsX0L@kernel.org \
    --to=jarkko@kernel.org \
    --cc=jgg@ziepe.ca \
    --cc=josh@joshtriplett.org \
    --cc=linux-integrity@vger.kernel.org \
    --cc=rust-for-linux@vger.kernel.org \
    --cc=tpm2@lists.linux.dev \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.