Jarkko Sakkinen
Posts
4941Following
327Followers
492OpenPGP: 3AB05486C7752FE1
Jarkko Sakkinen
jarkko
Edited 3 months ago
Despite having implemented SGX driver some years ago I think we all can agree that the existing confidential computing technologies suck like nothing else, right? :-)
In Linux kernel they are essentially proprietary pieces decorated as open source as the technology is unreachable by anyone and is really only option for companies such as Google.
SGX, SNP and TDX are technologies that FSF should be vocal about, not so much TPM (which open protocol specification).
E.g., with SGX Intel made a single NUC in 2018 to get ack from open source community for the kernel feature. Once it landed they have not continued to ship any affordable platforms for these technologies.
#linux #kernel #fsf #opensource
In Linux kernel they are essentially proprietary pieces decorated as open source as the technology is unreachable by anyone and is really only option for companies such as Google.
SGX, SNP and TDX are technologies that FSF should be vocal about, not so much TPM (which open protocol specification).
E.g., with SGX Intel made a single NUC in 2018 to get ack from open source community for the kernel feature. Once it landed they have not continued to ship any affordable platforms for these technologies.
#linux #kernel #fsf #opensource
1
4
10
Jarkko Sakkinen
jarkko
i just added parser for i8 as tpm2_protocol was able to parse u8 only previously :-) at least the type granularity is working
0
0
0
Jarkko Sakkinen
jarkko
my daughter had her first day at the local university hooray.
and she does not proactively hate me
biggest success in my life at least
and she does not proactively hate me
biggest success in my life at least
1
0
2
Jarkko Sakkinen
jarkko
Yet another post in the series of of C-senior and Rust-junior posts. I also expose this as group therapy sort of influencing reason i.e, perhaps there are kernel devs with some uncertainty when it comes to Rust.Thus, I expose mine :-)
I seem to do this two-step process a lot with Rust:
1. Refine the code for capability and implement that capability.
2. Decouple the capability from the (sub)crate.
E.g., in 0.7.0 I had reworked the whole code base so that lifetime-parameters would be relaxed and finally it was Any-compatible and I had dyn_eq and those shenanigans in the crate.
i.e., straight up the very first commit after tagging:
https://github.com/puavo-org/tpm2_library/commit/c704938ec64d31a1aaa1b88a3f686d5d25045c0b
I also felt ultimately stupid as I already had e.g. pretty_printer.rs that should have "showed me the way". Still I think it was worth it because of all bottlenecks the codebase had with lifetimes that I could not have noticed w/o first going way too far :-)
Pretty printer for reference: https://github.com/puavo-org/tpm2_library/blob/main/tpm2sh/src/pretty_printer.rs
In my Z-Modem crates next version I'm going to follow the learnings and make it walk and talk like some entity in futures/streams without being coupled to async and of course make it also zero deps:
https://codeberg.org/jarkko/zmodem2/commits/branch/main
I will demonstrate async-ready capability with refined versions of RZM and SZM. Then you can finally have ZModem in your next Tokio project :-)
#linux #rust #kernel
I seem to do this two-step process a lot with Rust:
1. Refine the code for capability and implement that capability.
2. Decouple the capability from the (sub)crate.
E.g., in 0.7.0 I had reworked the whole code base so that lifetime-parameters would be relaxed and finally it was Any-compatible and I had dyn_eq and those shenanigans in the crate.
i.e., straight up the very first commit after tagging:
https://github.com/puavo-org/tpm2_library/commit/c704938ec64d31a1aaa1b88a3f686d5d25045c0b
I also felt ultimately stupid as I already had e.g. pretty_printer.rs that should have "showed me the way". Still I think it was worth it because of all bottlenecks the codebase had with lifetimes that I could not have noticed w/o first going way too far :-)
Pretty printer for reference: https://github.com/puavo-org/tpm2_library/blob/main/tpm2sh/src/pretty_printer.rs
In my Z-Modem crates next version I'm going to follow the learnings and make it walk and talk like some entity in futures/streams without being coupled to async and of course make it also zero deps:
https://codeberg.org/jarkko/zmodem2/commits/branch/main
I will demonstrate async-ready capability with refined versions of RZM and SZM. Then you can finally have ZModem in your next Tokio project :-)
#linux #rust #kernel
1
1
3
I actually would have to test run it which I might do. It does have fixed-limited loops which I would imagine eBPF compiler to be able to unroll but other than that I'm not sure if there are backward jumps in tpm2_protocol. I'll try this some day :-)
Obviously it will fail when if I deploy it to filter but it is still interesting to see how and where.
Obviously it will fail when if I deploy it to filter but it is still interesting to see how and where.
0
0
0
The whole project has been about doing placeholder solution and then rewriting it. I even "rewrote" tpm2_protocol twice, first I thought it was fine when I got it working on static objects. Then I realized that I need to do things from ground up again tweaking the implementation from every possible location to make it robust enough with lifetimes to be able to use TpmObject as dyn trait.
But yeah, this is something I knew that would happen when aiming for product quality first time in Rust :-) It was a time investment really. I learned so much from this that I cannot really even begin to describe it ...
But yeah, this is something I knew that would happen when aiming for product quality first time in Rust :-) It was a time investment really. I learned so much from this that I cannot really even begin to describe it ...
0
0
0
Jarkko Sakkinen
jarkko
@Aissen yeah true :-) i'm actually looking forward to get rid of json. i already gave on json structure for pcrs as i can parse tpmlpcrselection on fly (or that is like the whole point of this project)
i.e. from json stack a migration is ongoing towards TPM object stack...
i.e. from json stack a migration is ongoing towards TPM object stack...
1
0
1
Jarkko Sakkinen
jarkko
@Aissen ah OK. for protocol i have standalone test program that outputs kselftest exit codes. For that subcrate I keep even dev-dependencies absolute zero.
tpm2sh is playground for testing that care but still i try to decrease its size when i find something where i can slim it down :-)
tpm2sh is playground for testing that care but still i try to decrease its size when i find something where i can slim it down :-)
1
0
0
Jarkko Sakkinen
jarkko
tpm2sh starts to look pretty good and has at least the features i want it to have for kernel testing.
tpm2_protocol is "kernel-ready" (including Box<dyn TpmObject>, which is essential for a driver uapi) and this the full list of commands it lacks for 100% TCG TPM 2.0 specification coverage:
https://github.com/puavo-org/tpm2_library/issues/4
I'm pretty much done with this project for the moment :-)
tpm2_protocol is "kernel-ready" (including Box<dyn TpmObject>, which is essential for a driver uapi) and this the full list of commands it lacks for 100% TCG TPM 2.0 specification coverage:
https://github.com/puavo-org/tpm2_library/issues/4
I'm pretty much done with this project for the moment :-)
1
0
0
Jarkko Sakkinen
jarkko
@Aissen sorry, what does "syn-free" mean? :-)
I just tagged 0.7.0 version you can check up yourself: https://github.com/puavo-org/tpm2_library
crypto crates add up a bit for tpm2sh but i want consolidate enough of that so that i can use this for e.g. kernel testing w/o having to use openssl too much
when i started to make tpm2sh it was this cover letter that i used as my source for minimal set of features that i need :-)
https://lore.kernel.org/linux-integrity/20240528210823.28798-1-jarkko@kernel.org/
I just tagged 0.7.0 version you can check up yourself: https://github.com/puavo-org/tpm2_library
crypto crates add up a bit for tpm2sh but i want consolidate enough of that so that i can use this for e.g. kernel testing w/o having to use openssl too much
when i started to make tpm2sh it was this cover letter that i used as my source for minimal set of features that i need :-)
https://lore.kernel.org/linux-integrity/20240528210823.28798-1-jarkko@kernel.org/
1
0
0
@devcoffee there's no need to access tpm i'd just like to know if i can run the parser inside eBPF
1
0
0
A spec update for a single new commands takes about 15 minutes to implement. I just di d that for ZGen2Phase:
tpm_struct! {
#[derive(Debug, PartialEq, Eq, Clone)]
TpmZGen2PhaseCommand,
TpmCc::ZGen2Phase,
false,
true,
1,
{
pub in_qsb: Tpm2bEccPoint,
pub in_qeb: Tpm2bEccPoint,
pub in_scheme: TpmiEccKeyExchange,
pub counter: u16,
}
}
tpm_response! {
#[derive(Debug, PartialEq, Eq, Clone)]
TpmZGen2PhaseResponse,
TpmCc::ZGen2Phase,
false,
true,
{
pub out_z1: Tpm2bEccPoint,
pub out_z2: Tpm2bEccPoint,
}
}
In addition a single line is required to ordered by cc dispatch list (there is compilation check for order):
(TpmZGen2PhaseCommand, TpmZGen2PhaseResponse, ZGen2Phase),
tpm_struct! {
#[derive(Debug, PartialEq, Eq, Clone)]
TpmZGen2PhaseCommand,
TpmCc::ZGen2Phase,
false,
true,
1,
{
pub in_qsb: Tpm2bEccPoint,
pub in_qeb: Tpm2bEccPoint,
pub in_scheme: TpmiEccKeyExchange,
pub counter: u16,
}
}
tpm_response! {
#[derive(Debug, PartialEq, Eq, Clone)]
TpmZGen2PhaseResponse,
TpmCc::ZGen2Phase,
false,
true,
{
pub out_z1: Tpm2bEccPoint,
pub out_z2: Tpm2bEccPoint,
}
}
In addition a single line is required to ordered by cc dispatch list (there is compilation check for order):
(TpmZGen2PhaseCommand, TpmZGen2PhaseResponse, ZGen2Phase),
0
0
0
It's a lot to say but I rarely cause over or underflows C. Cannot even remember when was the last time. But this structural integrity area is where I get more precision when using Rust.
I.e. I can almost formally do a yes/no check whether some sequence on-wire (given Box<dyn TpmCommand> capability) of data is command or response or something that differs only per byte of the set of legit commands or responses. That nails the key difference.
I.e. I can almost formally do a yes/no check whether some sequence on-wire (given Box<dyn TpmCommand> capability) of data is command or response or something that differs only per byte of the set of legit commands or responses. That nails the key difference.
1
0
0