kselftest and cargo

kselftest and cargo

[Jarkko Sakkinen]

Hi,

The pre-existing kselftest for TPM2 is derived works of my earlier Python
based rudimentary TPM2 stack called 'tpm2-scripts'.

In order to get more coverage and more mainintainable and extensible test
suite I'd like to eventually rewrite the tests with bash and tpm2sh, which
is a TPM2 cli written with Rust and based on my new TPM2 stack [1] [2].

Given linux-rust work, would it be acceptable to require cargo to install
a runner for kselftest? I'm finishing off now 0.11 version of the tool,
which will take some time (versions before that are honestly quite bad,
don't try them) but after that this would be something I'd like to
put together.

NOTE: while tpm2-protocol itself is Apache/MIT, tpm2sh is GPL3 licensed
command-line program (for what it is worth).

[1] https://github.com/puavo-org/tpm2sh
[2] https://git.kernel.org/pub/scm/linux/kernel/git/jarkko/tpm2-protocol.git/about/

BR, Jarkko

Re: kselftest and cargo

[Jarkko Sakkinen]

On Tue, Sep 16, 2025 at 04:48:22PM +0300, Jarkko Sakkinen wrote:
> Hi,
> 
> The pre-existing kselftest for TPM2 is derived works of my earlier Python
> based rudimentary TPM2 stack called 'tpm2-scripts'.
> 
> In order to get more coverage and more mainintainable and extensible test
> suite I'd like to eventually rewrite the tests with bash and tpm2sh, which
> is a TPM2 cli written with Rust and based on my new TPM2 stack [1] [2].
> 
> Given linux-rust work, would it be acceptable to require cargo to install
> a runner for kselftest? I'm finishing off now 0.11 version of the tool,
> which will take some time (versions before that are honestly quite bad,
> don't try them) but after that this would be something I'd like to
> put together.
> 
> NOTE: while tpm2-protocol itself is Apache/MIT, tpm2sh is GPL3 licensed
> command-line program (for what it is worth).

Also tpm2-protocol is dependencyless, no crazy corporate TPM2
shenanigans and daemons involved etc., meaning that overall tpm2sh is
quite self-contained and good fit but 8 KSLOC not really to be imported
(the size comes from built-in TPM2 emulator, policy expression language
and advanced import functionality that directly converts PKCS#8 to TPM2
Key ASN.1 DEr/PEM all super useful for all sorts of testing purposes).


> 
> [1] https://github.com/puavo-org/tpm2sh
> [2] https://git.kernel.org/pub/scm/linux/kernel/git/jarkko/tpm2-protocol.git/about/
> 
> BR, Jarkko
> 
> 

Re: kselftest and cargo

[Shuah Khan]

On 9/16/25 07:48, Jarkko Sakkinen wrote:
> Hi,
> 
> The pre-existing kselftest for TPM2 is derived works of my earlier Python
> based rudimentary TPM2 stack called 'tpm2-scripts'.
> 
> In order to get more coverage and more mainintainable and extensible test
> suite I'd like to eventually rewrite the tests with bash and tpm2sh, which
> is a TPM2 cli written with Rust and based on my new TPM2 stack [1] [2].
> 
> Given linux-rust work, would it be acceptable to require cargo to install
> a runner for kselftest? I'm finishing off now 0.11 version of the tool,
> which will take some time (versions before that are honestly quite bad,
> don't try them) but after that this would be something I'd like to
> put together.

Probably fine - how does this impact kselftest default run?

> 
> NOTE: while tpm2-protocol itself is Apache/MIT, tpm2sh is GPL3 licensed
> command-line program (for what it is worth).
> 
> [1] https://github.com/puavo-org/tpm2sh
> [2] https://git.kernel.org/pub/scm/linux/kernel/git/jarkko/tpm2-protocol.git/about/
> 
> BR, Jarkko
> 
> 

thanks,
-- Shuah

Re: kselftest and cargo

[Jarkko Sakkinen]

On Tue, Sep 16, 2025 at 04:39:37PM -0600, Shuah Khan wrote:
> On 9/16/25 07:48, Jarkko Sakkinen wrote:
> > Hi,
> > 
> > The pre-existing kselftest for TPM2 is derived works of my earlier Python
> > based rudimentary TPM2 stack called 'tpm2-scripts'.
> > 
> > In order to get more coverage and more mainintainable and extensible test
> > suite I'd like to eventually rewrite the tests with bash and tpm2sh, which
> > is a TPM2 cli written with Rust and based on my new TPM2 stack [1] [2].
> > 
> > Given linux-rust work, would it be acceptable to require cargo to install
> > a runner for kselftest? I'm finishing off now 0.11 version of the tool,
> > which will take some time (versions before that are honestly quite bad,
> > don't try them) but after that this would be something I'd like to
> > put together.
> 
> Probably fine - how does this impact kselftest default run?

OK so this was early query: I might introduce such test as part
of series that hasa waited for long time for an update [1]. I can
use tpm2sh more easily to reproduce equivalent crypto as kernel
does and make a test that can compare the results in a meaningful
manner. I also plan to relocate tpm2sh as part of git.kernel.org
custody from Github, as its main dependency tpm2-protocol crate 
already is [2].

I went over the top in the original mail: most definitely it makes
sense to retain the pre-existing test, and such "Rust-enhanced"
test should be conditional, and can instead of depending on cargo
simply do "command -v" in order to check the existence of tpm2sh
and output installation instructions if it is missing.

With those precautions it should be somewhat harmless unless you
actually want to run that test.

Thanks for quick response!

[1] https://lore.kernel.org/linux-integrity/20240528210823.28798-1-jarkko@kernel.org/
[2] https://git.kernel.org/pub/scm/linux/kernel/git/jarkko/tpm2-protocol.git

BR, Jarkko

Re: kselftest and cargo

[Jarkko Sakkinen]

On Thu, Sep 18, 2025 at 06:06:31PM +0300, Jarkko Sakkinen wrote:
> On Tue, Sep 16, 2025 at 04:39:37PM -0600, Shuah Khan wrote:
> > On 9/16/25 07:48, Jarkko Sakkinen wrote:
> > > Hi,
> > > 
> > > The pre-existing kselftest for TPM2 is derived works of my earlier Python
> > > based rudimentary TPM2 stack called 'tpm2-scripts'.
> > > 
> > > In order to get more coverage and more mainintainable and extensible test
> > > suite I'd like to eventually rewrite the tests with bash and tpm2sh, which
> > > is a TPM2 cli written with Rust and based on my new TPM2 stack [1] [2].
> > > 
> > > Given linux-rust work, would it be acceptable to require cargo to install
> > > a runner for kselftest? I'm finishing off now 0.11 version of the tool,
> > > which will take some time (versions before that are honestly quite bad,
> > > don't try them) but after that this would be something I'd like to
> > > put together.
> > 
> > Probably fine - how does this impact kselftest default run?
> 
> OK so this was early query: I might introduce such test as part
> of series that hasa waited for long time for an update [1]. I can
> use tpm2sh more easily to reproduce equivalent crypto as kernel
> does and make a test that can compare the results in a meaningful
> manner. I also plan to relocate tpm2sh as part of git.kernel.org
> custody from Github, as its main dependency tpm2-protocol crate 
> already is [2].

Some motivation context, I left out on doing the aforementioned
patch set because I did not see importing TPM2 keys useful enough
application but recently I've been dealing with remote attestation
and that levels up the feature something quite useful.

I.e. so called attestation identity keys are persisted to the NVRAM of a
TPM chip and it would great if kernel could at boot time reserve
selected (in the command-line) NV indexes and wrap them up into keyring
keys. Since in UKI model command-line is signed that effectively locks
them in into controlled use only through keyring as kernel can
guard that via the device.

I could put tons more detail into this but point to open up this
complexity is that getting all cryptography right is easiest done
by reproducing it in a test in user space and comparing the 
results, and Rust and the crate I did give sort of powerful
way to describe all this. And also because of the complexity
it needs to be anchroed with some kind of sufficient test.

BR, Jarkko

Re: kselftest and cargo

[Shuah Khan]

On 9/18/25 09:15, Jarkko Sakkinen wrote:
> On Thu, Sep 18, 2025 at 06:06:31PM +0300, Jarkko Sakkinen wrote:
>> On Tue, Sep 16, 2025 at 04:39:37PM -0600, Shuah Khan wrote:
>>> On 9/16/25 07:48, Jarkko Sakkinen wrote:
>>>> Hi,
>>>>
>>>> The pre-existing kselftest for TPM2 is derived works of my earlier Python
>>>> based rudimentary TPM2 stack called 'tpm2-scripts'.
>>>>
>>>> In order to get more coverage and more mainintainable and extensible test
>>>> suite I'd like to eventually rewrite the tests with bash and tpm2sh, which
>>>> is a TPM2 cli written with Rust and based on my new TPM2 stack [1] [2].
>>>>
>>>> Given linux-rust work, would it be acceptable to require cargo to install
>>>> a runner for kselftest? 

What is runner for kselftest in this context?

I'm finishing off now 0.11 version of the tool,
>>>> which will take some time (versions before that are honestly quite bad,
>>>> don't try them) but after that this would be something I'd like to
>>>> put together.
>>>
>>> Probably fine - how does this impact kselftest default run?
>>
>> OK so this was early query: I might introduce such test as part
>> of series that hasa waited for long time for an update [1]. I can
>> use tpm2sh more easily to reproduce equivalent crypto as kernel
>> does and make a test that can compare the results in a meaningful
>> manner. I also plan to relocate tpm2sh as part of git.kernel.org
>> custody from Github, as its main dependency tpm2-protocol crate
>> already is [2].
> 
> Some motivation context, I left out on doing the aforementioned
> patch set because I did not see importing TPM2 keys useful enough
> application but recently I've been dealing with remote attestation
> and that levels up the feature something quite useful.
> 
> I.e. so called attestation identity keys are persisted to the NVRAM of a
> TPM chip and it would great if kernel could at boot time reserve
> selected (in the command-line) NV indexes and wrap them up into keyring
> keys. Since in UKI model command-line is signed that effectively locks
> them in into controlled use only through keyring as kernel can
> guard that via the device.
> 
> I could put tons more detail into this but point to open up this
> complexity is that getting all cryptography right is easiest done
> by reproducing it in a test in user space and comparing the
> results, and Rust and the crate I did give sort of powerful
> way to describe all this. And also because of the complexity
> it needs to be anchroed with some kind of sufficient test.
> 

I would say get this in a shape where you can share it for review.
We can discuss the changes. One thing to keep in mind is dependencies
for kselftest default run need to be minimal so these tests can run
on rings with minimal tool support.

thanks,
-- Shuah

Re: kselftest and cargo

[Jarkko Sakkinen]

On Thu, Sep 18, 2025 at 10:04:13AM -0600, Shuah Khan wrote:
> On 9/18/25 09:15, Jarkko Sakkinen wrote:
> > On Thu, Sep 18, 2025 at 06:06:31PM +0300, Jarkko Sakkinen wrote:
> > > On Tue, Sep 16, 2025 at 04:39:37PM -0600, Shuah Khan wrote:
> > > > On 9/16/25 07:48, Jarkko Sakkinen wrote:
> > > > > Hi,
> > > > > 
> > > > > The pre-existing kselftest for TPM2 is derived works of my earlier Python
> > > > > based rudimentary TPM2 stack called 'tpm2-scripts'.
> > > > > 
> > > > > In order to get more coverage and more mainintainable and extensible test
> > > > > suite I'd like to eventually rewrite the tests with bash and tpm2sh, which
> > > > > is a TPM2 cli written with Rust and based on my new TPM2 stack [1] [2].
> > > > > 
> > > > > Given linux-rust work, would it be acceptable to require cargo to install
> > > > > a runner for kselftest?
> 
> What is runner for kselftest in this context?

It would really just a bash commanding tpm2sh and with conditional
check the binding is kept loose.

BR, Jarkko