Jarkko Sakkinen
Posts
4874Following
323Followers
490OpenPGP: 3AB05486C7752FE1
It's immature as hell but I think i've made correct base decisions (which you can only do at this point). Right now I'm fixing some macros because i did "final polishments before putting this out" and did some awful mistakes :-) This always happens. Yesterday morning things were better but then I started to tweak ...
I think, considering rust-linux, one interesting feature could be swtpms, which becomes realistic goal if you make right conclusions of what you're observing. I don't actually know could you create endosement infrastructure where swtpm instances have their endorsement keys certified by the TPM chip (which is endorsed by the manufacturer).
In the previous TPM stack implementations i think that core mistake that has been repeatedly made is thinking that you have a client and chip or emulator, which is not from technical perspective correct assesment.
QEMU is an emulator. TPM2 is a protocol. That is stating the obvious but for some reason that is the exact blind spot.
I think, considering rust-linux, one interesting feature could be swtpms, which becomes realistic goal if you make right conclusions of what you're observing. I don't actually know could you create endosement infrastructure where swtpm instances have their endorsement keys certified by the TPM chip (which is endorsed by the manufacturer).
In the previous TPM stack implementations i think that core mistake that has been repeatedly made is thinking that you have a client and chip or emulator, which is not from technical perspective correct assesment.
QEMU is an emulator. TPM2 is a protocol. That is stating the obvious but for some reason that is the exact blind spot.
0
0
0
Jarkko Sakkinen
jarkko
@lkundrak ya i mean i don't want to end up in a situation where i see a rust patch set and i try to say that the code is just plain bad and it is interpreted me being toxic person :-) and all reported in the usual news outlets... i can relate to the pain and suffering some maintainers have had tbh.
1
0
0
Jarkko Sakkinen
jarkkoThis makes me happy:
tpm_struct!(
#[derive(Debug, PartialEq, Eq, Clone)]
TpmPcrEventCommand,
TpmCc::PcrEvent,
TpmSt::Sessions,
1,
{
pub event_data: Tpm2b,
}
);
tpm_response!(
#[derive(Debug, Default, PartialEq, Eq, Clone)]
TpmPcrEventResponse,
TpmCc::PcrEvent,
TpmSt::Sessions,
{
pub digests: TpmlDigestValues,
}
);
Also the types inside use the same system (in fact tpm_struct is shared macro with data types and commands). This will generate full parsing and building for both commands and responses - all without heap involved.
1
0
0
Jarkko Sakkinen
repeated
repeated
Here's another 3D print project: a mounting bracket for W1GHZ dual-band microwave feed horns (10 GHz + 24 GHz).
https://github.com/xjamesmorris/dual-band-10-24-ghz-feed-mount
#amateurradio #hamradio #3dprinting #rf #microwave
https://github.com/xjamesmorris/dual-band-10-24-ghz-feed-mount
#amateurradio #hamradio #3dprinting #rf #microwave
0
3
7
Licensing is used as security measure. I.e. crate itself is Apache/MIT but cli is strict GPL3. It's exactly because then you know that a binary is "accountable". It's a trick I've learned how Signal creates security layers via licensing (they show how AGPL can be commercially appealing pick).
0
0
0
the killer feature of the TPM stack itself compared to any other is to be able to speak in responses and interpret commands. For this use case you really only have MS TPM 2.0 simulator and swatpm as of today (swtpm is great tho). The protocol crate is made for interoperability layers of non-TPM crypto chips and hardware/software keystores alike.
1
0
0
Jarkko Sakkinen
jarkko
Edited 2 months ago
I'm ready to push this online, but not for a while tag a release because cli should be made to work optimally.
E.g., policy-secret is placeholder. it would much nicer to have "policy [--train] <expression>" with some combinatorial language.
It could take advantage of object references provided my baked-in stack machine:
1. Subcommands a take list of JSON objects from stdin and consume as many as they need from top of te stack.
2. Each subcommand then produce results to the top.
Of course some things come through arguments (e.g. for key creation I have "--persistent").
Also perhaps load and import should be combined to a single smart command. The point is that this is where I don't know what to do exactly and changes for cli interface are welcome :-) I'm now happy that I got allocs and panics away from protocol crate making it "linux-rust ready".
In the protocol crate itself there is one single puzzle where constant improvement makes sense both in kernel and user space: narrowing the delta between "SIZE" and "len()" of TpmSize trait. Ideally the delta would be zero t some point. To be usable in kernel I've now reach that goal (easily) but optimizing this equation makes it substantially better.
E.g., policy-secret is placeholder. it would much nicer to have "policy [--train] <expression>" with some combinatorial language.
It could take advantage of object references provided my baked-in stack machine:
1. Subcommands a take list of JSON objects from stdin and consume as many as they need from top of te stack.
2. Each subcommand then produce results to the top.
Of course some things come through arguments (e.g. for key creation I have "--persistent").
Also perhaps load and import should be combined to a single smart command. The point is that this is where I don't know what to do exactly and changes for cli interface are welcome :-) I'm now happy that I got allocs and panics away from protocol crate making it "linux-rust ready".
In the protocol crate itself there is one single puzzle where constant improvement makes sense both in kernel and user space: narrowing the delta between "SIZE" and "len()" of TpmSize trait. Ideally the delta would be zero t some point. To be usable in kernel I've now reach that goal (easily) but optimizing this equation makes it substantially better.
2
1
2
Jarkko Sakkinen
jarkko
cannot even imagine what amazing things i end up doing with my zmodem2 crate implementation now that i've learned how to really put protocol shenanigans in place with rust ;-)
0
1
1
It also optimizes performance as that zeros out marshalling and unmarshalling. Internal representation can be buffer to which data structures are mapped.
For capacity it’s not exact science i.e.:
/// Buffer properties for an object.
pub trait TpmBuffer {
/// Capacity at most required to strore an object implementing the type.
const BUFFER_CAPACITY: usize;
pub fn len() -> usize;
}
E.g., for digest this would the maximum digest. For TPMT_PUBLIC capacity would 640 bytes to fit 4096-bit RSA key.
At runtime, however, the exact size is calculated by summing up “recursively”. Lengths also when summed up point the exact location in the byte stream where an attribute is located. I.e., it’s a zerocopy. I
0
0
0
and if tpm_transmit() was implemented with rust, and this protocol crate was used, it could both verify:
1. command size in byte granularity
2. response size in byte granularity, which much more interesting use case and would be hard to nail with C (instead you have just some max value). i.e. it could detect even slight variation to the expected response length from a device (and devices are hostile because we don't control them).
i.e. a measurable objective benefit not a usual borrow checker catch-22. i would definitely support doing something like this.
1. command size in byte granularity
2. response size in byte granularity, which much more interesting use case and would be hard to nail with C (instead you have just some max value). i.e. it could detect even slight variation to the expected response length from a device (and devices are hostile because we don't control them).
i.e. a measurable objective benefit not a usual borrow checker catch-22. i would definitely support doing something like this.
1
0
0
Jarkko Sakkinen
jarkko
Edited 2 months ago
going to make tpm2_protocol also allocless as it is low-hanging fruit given that it know exactly how much data to expect given full structural understanding of commands and responses. so e.g. in kernel one would mostly (always) use just stack because you know what you're going to get and usually it is not whole a lot.
it started as a framework of structs, and it turned into framework generating a framework of structs from a protocol description :-)
it started as a framework of structs, and it turned into framework generating a framework of structs from a protocol description :-)
1
0
0
Jarkko Sakkinen
jarkko
first time for a long update to zmodem2: https://crates.io/crates/zmodem2/0.1.3
preparation release to upgrade rzm and szm to something that could be considered nicer than rz and sz.
preparation release to upgrade rzm and szm to something that could be considered nicer than rz and sz.
0
0
1
Jarkko Sakkinen
jarkko
Edited 2 months ago
For tpm2-cli I'm planning to do tests with it by using tpm2_protocol as the mocked TPM chip.
It should demonstrate the unipolarity quite well and also possibilities to use the crate as interoperability layer for alt keystores.
It's quite maintainable as I've developed a domain language for declaratively describing TCG specification:
❯ git grep macro_rules
protocol/src/command/util.rs:macro_rules! tpm_message {
protocol/src/command/util.rs:macro_rules! tpm_response_with_params {
protocol/src/command/util.rs:macro_rules! tpm_dispatch {
protocol/src/command/util.rs: macro_rules! tpm_command_parser {
protocol/src/command/util.rs: macro_rules! tpm_response_parser {
protocol/src/lib.rs:macro_rules! tpm_handle {
protocol/src/lib.rs:macro_rules! tpm_bitflags {
protocol/src/lib.rs:macro_rules! tpm_enum {
protocol/src/lib.rs:macro_rules! tpm_integer {
protocol/src/structure/mod.rs:macro_rules! tpm_struct {
protocol/src/structure/tpm2b.rs:macro_rules! tpm2b {
protocol/src/structure/tpml.rs:macro_rules! tpml {
I've produced now 5K SLOC of non-boilerplate code since I got the inspiration last Sunday (with not much sleep), and total size of crate is about 6K SLOC making it my largest Rust project so far written single-handidly :-) It was kind of effort that if you don't just push it through it never will be finished.
#linux #tpm
It should demonstrate the unipolarity quite well and also possibilities to use the crate as interoperability layer for alt keystores.
It's quite maintainable as I've developed a domain language for declaratively describing TCG specification:
❯ git grep macro_rules
protocol/src/command/util.rs:macro_rules! tpm_message {
protocol/src/command/util.rs:macro_rules! tpm_response_with_params {
protocol/src/command/util.rs:macro_rules! tpm_dispatch {
protocol/src/command/util.rs: macro_rules! tpm_command_parser {
protocol/src/command/util.rs: macro_rules! tpm_response_parser {
protocol/src/lib.rs:macro_rules! tpm_handle {
protocol/src/lib.rs:macro_rules! tpm_bitflags {
protocol/src/lib.rs:macro_rules! tpm_enum {
protocol/src/lib.rs:macro_rules! tpm_integer {
protocol/src/structure/mod.rs:macro_rules! tpm_struct {
protocol/src/structure/tpm2b.rs:macro_rules! tpm2b {
protocol/src/structure/tpml.rs:macro_rules! tpml {
I've produced now 5K SLOC of non-boilerplate code since I got the inspiration last Sunday (with not much sleep), and total size of crate is about 6K SLOC making it my largest Rust project so far written single-handidly :-) It was kind of effort that if you don't just push it through it never will be finished.
#linux #tpm
0
0
0
Jarkko Sakkinen
jarkko
I've had really good experiences working with Oracle's kernel security engineers in and out (in private threads) of LKML for past year. They seem to get the difference between business goals and schedules, and the goals in the mainline, and not whole a lot of useless debating. They know how to behave it seems ...
Just stands out from the crowd somehow so had to let ths out :-)
Just stands out from the crowd somehow so had to let ths out :-)
0
0
0
Jarkko Sakkinen
jarkko
Edited 2 months ago
The design that I'm aiming with this cli interface is that it would be usable for TPM2 interaction for application written shell (bash, fish etc.) scripting languages (i.e. password managers and similar).
When it starts to be easy to combine the subcommands in script this should be in fairly good state.
Import and load support keys in ASN.1 format, which is used by kernel for loading trusted keys. Software crypto for now is with libssl bindings as it is sort for safe-play for crypto (CVEs, security hotfixes, auditing) and also it is what I'm most used to in kernel development (and that is what I ultimately care about).
When it starts to be easy to combine the subcommands in script this should be in fairly good state.
Import and load support keys in ASN.1 format, which is used by kernel for loading trusted keys. Software crypto for now is with libssl bindings as it is sort for safe-play for crypto (CVEs, security hotfixes, auditing) and also it is what I'm most used to in kernel development (and that is what I ultimately care about).
0
0
1