Jarkko Sakkinen
Posts
4873Following
323Followers
491OpenPGP: 3AB05486C7752FE1
@Netux It has been for me problematic to understand why we care about Rust because trivial memory errors are not something we would need a whole new language ecosystem. It's really this ability compose/decompose data that matters in Rust for kernel IMHO. In quite many categories of drivers it would take them to the next level if they could look more than just "max length" or similar attributes. Wanted to write it down while I had the thought on my mind :-)
1
0
1
Jarkko Sakkinen
jarkko
Now it is time phase out doing this and detach myself from the grip of hyperfocus ...
https://lore.kernel.org/rust-for-linux/aKUTF6lu5JetDJxX@kernel.org/T/#u
Ton of stuff that I did not do during last three weeks that I should had done (mainly outside of work) so navigating myself to that direction :-) I just could not stop, once I got really started.
Also I sleeping might be good idea once in a while :-)
#linux #kernel #tpm #rust
https://lore.kernel.org/rust-for-linux/aKUTF6lu5JetDJxX@kernel.org/T/#u
Ton of stuff that I did not do during last three weeks that I should had done (mainly outside of work) so navigating myself to that direction :-) I just could not stop, once I got really started.
Also I sleeping might be good idea once in a while :-)
#linux #kernel #tpm #rust
1
1
5
Also this CoC code creates literally enclaves (pun intended) of code to arch having very low chance to get reviewed with the same standards as other non-CoC arch code, given that there is a low number of maintainers with ability to run it.
And even those maintainers who can run it usually have no local hardware but instead have to use some company internal cloud, given how expensive hardware is and also the form factor (noisy power eating server rack) is dysoptimal for devs to begin with.
SGX is not as bad as SNP or TDX given that it is based on memory pages instead of virtualization and this is consolidated to its own driver, but even SGX is practially inaccessible for most and AFAIK there's no official QEMU emulation for it (shame on you Intel).
TEE based on VM (SNP, TDX) is IMHO a broken security concept to begin with but that's another topic.
And even those maintainers who can run it usually have no local hardware but instead have to use some company internal cloud, given how expensive hardware is and also the form factor (noisy power eating server rack) is dysoptimal for devs to begin with.
SGX is not as bad as SNP or TDX given that it is based on memory pages instead of virtualization and this is consolidated to its own driver, but even SGX is practially inaccessible for most and AFAIK there's no official QEMU emulation for it (shame on you Intel).
TEE based on VM (SNP, TDX) is IMHO a broken security concept to begin with but that's another topic.
0
0
0
Jarkko Sakkinen
jarkko
12000 SLOC for full TCG TPM 2.0 protocol spefication in three weeks (with about 1000 SLOC of initial code I made year ago).
This includes also tpm2sh. The protocol crate is only ~7000 SLOC.
Now that tpm2_protocol is "complete", I'd believe that it will also slim down over time because first version always the fattest.
I think tpm2_protocol would be the right basis for Linux Rust support for TPM2 but it definitely must mature some time so that low-hanging bugs etc are fixed.
tpm2sh is still quite immature but it is just a test program :-) It has quite a lot of crypto code but use that your own responsibility. I've added that to help with testing now meant for use in production.
#linux #kernel #tpm #rust
This includes also tpm2sh. The protocol crate is only ~7000 SLOC.
Now that tpm2_protocol is "complete", I'd believe that it will also slim down over time because first version always the fattest.
I think tpm2_protocol would be the right basis for Linux Rust support for TPM2 but it definitely must mature some time so that low-hanging bugs etc are fixed.
tpm2sh is still quite immature but it is just a test program :-) It has quite a lot of crypto code but use that your own responsibility. I've added that to help with testing now meant for use in production.
#linux #kernel #tpm #rust
0
0
0
Jarkko Sakkinen
jarkko
Well... hell... TCG TPM 2.0 specification 184 minus one command coverage.
2
0
0
If you read what FSF has said about TPM over the years, a lot of it applies exactly to confidential computing.
Also they lock-in to company CA meaning that:
1. AMD, ARM or Intel can brick your hardware.
2. If they decease the business, your hardware will be bricked.
Also they lock-in to company CA meaning that:
1. AMD, ARM or Intel can brick your hardware.
2. If they decease the business, your hardware will be bricked.
1
6
8
Jarkko Sakkinen
jarkko
Edited 2 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