Jarkko Sakkinen
Posts
4941Following
327Followers
492OpenPGP: 3AB05486C7752FE1
I.e. in short what is done, is done. It cannot be changed. However we should ask a lot more than we ask today from CPU vendors and add constraints and clauses a lot more.
E.g, when accepting a feature it would be a great policy to stop accepting feature improvements if they play like this.
E.g, when accepting a feature it would be a great policy to stop accepting feature improvements if they play like this.
1
0
3
Jarkko Sakkinen
jarkko
Edited 2 months ago
IMHO learnings from SGX, SNP and TDX: we should simply stop accepting enterprisy CPU features UNLESS there's guaranteed flow of reasonably priced SDPs, EVEN if they are not profitable for the CPU company.
E.g., in SGX, Intel delivered exactly one generation of NUCs in order to comply what we agreed on at Linux Plumbers 2016. Once the feature was in the mainline it was end of story for developer accessible hardware. And still after that SNP and TDX have been included, which is plain stupid.
It's hard to take away user facing code from kernel once it is included but it would be the best possible policy and constraint to take only bug fixes up until we have cheap SDPs for the confidential computing CPU features.
Let's shutdown any other improvements up until that. Not a decision maker on x86 tree but I have right for my opinion at least :-)
EDIT: I think I make my case without "PS" part :-) This is still how things have went and based on facts (I've witnessed the whole process).
#linux #kernel #intel #amd
E.g., in SGX, Intel delivered exactly one generation of NUCs in order to comply what we agreed on at Linux Plumbers 2016. Once the feature was in the mainline it was end of story for developer accessible hardware. And still after that SNP and TDX have been included, which is plain stupid.
It's hard to take away user facing code from kernel once it is included but it would be the best possible policy and constraint to take only bug fixes up until we have cheap SDPs for the confidential computing CPU features.
Let's shutdown any other improvements up until that. Not a decision maker on x86 tree but I have right for my opinion at least :-)
EDIT: I think I make my case without "PS" part :-) This is still how things have went and based on facts (I've witnessed the whole process).
#linux #kernel #intel #amd
1
0
4
Jarkko Sakkinen
repeated
repeated
Jukka Niiranen
jukkan@mstdn.social"Who needs an App Store? You've got the Nokia PC Suite software on a CD-ROM! Just plug the proprietary cable into your Symbian S60 device, boot up your Windows PC, and away you go. THIS is the smartphone experience for people who are serious about mobile computing."
#Nokia #Symbian #smartphone #retrophone
0
3
0
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.
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.
0
0
0
Jarkko Sakkinen
jarkko
The next thing with tpm2_protocol is obviously the figures!
I.e. creating a stress that measures the delta between compile-time estimated size and run-time realized size.
This spun up from my friend Philip Tricca asking about stack usage. I definitely want to know the truth and also catch regressions on this side that might be caused by new commits.
Obviously during construction time this has not been a priority but now it is time to level it up.
One of first commits to wiping away the excess fat is (already in 0.10.0):
https://git.kernel.org/pub/scm/linux/kernel/git/jarkko/tpm2-protocol.git/commit/?id=cd6641bf9e8c8fde8726bece9eb6cdc630d893c2
#linux #kernel #tpm #rust
I.e. creating a stress that measures the delta between compile-time estimated size and run-time realized size.
This spun up from my friend Philip Tricca asking about stack usage. I definitely want to know the truth and also catch regressions on this side that might be caused by new commits.
Obviously during construction time this has not been a priority but now it is time to level it up.
One of first commits to wiping away the excess fat is (already in 0.10.0):
https://git.kernel.org/pub/scm/linux/kernel/git/jarkko/tpm2-protocol.git/commit/?id=cd6641bf9e8c8fde8726bece9eb6cdc630d893c2
#linux #kernel #tpm #rust
0
0
0
Jarkko Sakkinen
jarkko
Edited 2 months ago
As of today can we 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.
#linux #kernel #rust #tpm
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.
#linux #kernel #rust #tpm
1
1
1
Jarkko Sakkinen
jarkko
should usage normally cause exit code 1 or 0?
right now e.g.,
❯ sudo target/debug/tpm2sh unseal
tpm2sh-unseal
Unseals a keyedhash object
USAGE:
tpm2sh unseal [OPTIONS]
OPTIONS:
--password <PASSWORD> Authorization value
-h, --help Print help information
~/work/github.com/puavo-org/tpm2sh main
❯ echo $status
1
It checks if stdin is open for the sake of pipelien and if not it shows usage.
right now e.g.,
❯ sudo target/debug/tpm2sh unseal
tpm2sh-unseal
Unseals a keyedhash object
USAGE:
tpm2sh unseal [OPTIONS]
OPTIONS:
--password <PASSWORD> Authorization value
-h, --help Print help information
~/work/github.com/puavo-org/tpm2sh main
❯ echo $status
1
It checks if stdin is open for the sake of pipelien and if not it shows usage.
1
0
0
Jarkko Sakkinen
jarkko
the very last spam alert:
https://lore.kernel.org/rust-for-linux/aKfaR-h6Itc38qfl@kernel.org/T/#u
moving to on hold as tpm2_protocol is/will be mailing list based project.
tpm2sh has a new github location: https://github.com/puavo-org/tpm2sh
#linux #kernel #tpm #rust
https://lore.kernel.org/rust-for-linux/aKfaR-h6Itc38qfl@kernel.org/T/#u
moving to on hold as tpm2_protocol is/will be mailing list based project.
tpm2sh has a new github location: https://github.com/puavo-org/tpm2sh
#linux #kernel #tpm #rust
0
0
1
Jarkko Sakkinen
jarkko
Edited 2 months ago
The first independent release of the protocol: https://crates.io/crates/tpm2-protocol
Git: https://git.kernel.org/pub/scm/linux/kernel/git/jarkko/tpm2-protocol.git
Release notes:
tag 0.10.0
Tagger: Jarkko Sakkinen <jarkko.sakkinen@iki.fi>
Date: Fri Aug 22 04:45:40 2025 +0300
Release 0.10.0
- chore: refactor into standalone crate
- refactor(tpm2_protocol): reduce defaults
- refactor(tpm2_protocol): merge TpmuSigScheme and TpmuAsymScheme
- refactor(tpm2_protocol): decouple command building
- fix(tpm2_protocol): trailing data
- refactor(tpm2_protocol): remove MAC definitions
- tests(tpm2_protocol)
- fix(tpm2-protocol): TpmuAttest error code
- tests: migrate dyn trait test to tpm2_protocol
- fix(tpm2_protocol): correct serialization logic
- refactor: InternalError -> Unreachable
- tests(tpm2_protocol): fix compilation errors
- fix(tpm2_protocol): StartAuthSession response
- refactor!(tpm2_protocol): drop tpm_response! and TpmParameters
- fix!(tpm2_protocol): DO NOT export submodules
- refactor(tpm2_protocol): adjust buffer debug output
- fix(tpm2_protocol): TpmRc::base() return code
-----BEGIN PGP SIGNATURE-----
iHUEABYIAB0WIQRE6pSOnaBC00OEHEIaerohdGur0gUCaKfLxAAKCRAaerohdGur
0nY/AP9/4HMLP+wY0h5tQSnbzmIajNzzBAoWIA7nA8dIkcQ8RQEAxhK/MrKKT7iQ
j2rEvvKdgWPdHtPhZWzUahuZnW6LIgA=
=RfaI
-----END PGP SIGNATURE-----
#linux #kernel #tpm #rust
Git: https://git.kernel.org/pub/scm/linux/kernel/git/jarkko/tpm2-protocol.git
Release notes:
tag 0.10.0
Tagger: Jarkko Sakkinen <jarkko.sakkinen@iki.fi>
Date: Fri Aug 22 04:45:40 2025 +0300
Release 0.10.0
- chore: refactor into standalone crate
- refactor(tpm2_protocol): reduce defaults
- refactor(tpm2_protocol): merge TpmuSigScheme and TpmuAsymScheme
- refactor(tpm2_protocol): decouple command building
- fix(tpm2_protocol): trailing data
- refactor(tpm2_protocol): remove MAC definitions
- tests(tpm2_protocol)
- fix(tpm2-protocol): TpmuAttest error code
- tests: migrate dyn trait test to tpm2_protocol
- fix(tpm2_protocol): correct serialization logic
- refactor: InternalError -> Unreachable
- tests(tpm2_protocol): fix compilation errors
- fix(tpm2_protocol): StartAuthSession response
- refactor!(tpm2_protocol): drop tpm_response! and TpmParameters
- fix!(tpm2_protocol): DO NOT export submodules
- refactor(tpm2_protocol): adjust buffer debug output
- fix(tpm2_protocol): TpmRc::base() return code
-----BEGIN PGP SIGNATURE-----
iHUEABYIAB0WIQRE6pSOnaBC00OEHEIaerohdGur0gUCaKfLxAAKCRAaerohdGur
0nY/AP9/4HMLP+wY0h5tQSnbzmIajNzzBAoWIA7nA8dIkcQ8RQEAxhK/MrKKT7iQ
j2rEvvKdgWPdHtPhZWzUahuZnW6LIgA=
=RfaI
-----END PGP SIGNATURE-----
#linux #kernel #tpm #rust
0
0
4
@monsieuricon goals here summarized: a protocol crate (importable) that could be in future shared by TPM-RS and Linux kernel (both of which care about import not about using it as dep).
0
0
2
Jarkko Sakkinen
jarkko
Edited 2 months ago
I migrated dyn trait (or Box<dyn TpmObject>) as part of tpm2_protocol test suite just to demonstrate that on-wire TPM2 protocol can be dynamically detected without any spurious dependencies ;-)
Screencast demonstrates also the time that it takes to run the full kselftest compatible test suite.
#linux #kernel #tpm #rust
Screencast demonstrates also the time that it takes to run the full kselftest compatible test suite.
#linux #kernel #tpm #rust
0
0
1
Jarkko Sakkinen
repeated
repeated
Sven Peter
sven@social.treehouse.systemsI've finally just submitted the RFC series for USB3 support on Apple Silicon machines. RFC because the entire Type-C machinery spans multiple subsystems and has quite a few quirks which makes the entire thing rather annoying to deal with and I'm not 100% convinced about the current approach.
This also includes some initial work for DisplayPort-altmode and USB4/Thunderbolt but both will require much more work after this is upstream, so don't get your hopes up just yet.
https://lore.kernel.org/asahi/20250821-atcphy-6-17-v1-0-172beda182b8@kernel.org/
4
5
0