Conversation

Jarkko Sakkinen

Edited 3 days 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 :-)
1
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
0
0

Jarkko Sakkinen

Edited 2 days ago

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