rasn is good stuff for custom non-established DER formats. Full TPM key ASN.1 spec + my extensions (parentName, parentPubKey):

https://github.com/puavo-org/tpm2sh/blob/main/src/key/tpm_key.rs

It took me like 30 minutes after reading tutorial a bit get ongoing.

test driver obviously wil have differences but most of parsing code etc. translate.

great now i have a single data-drive test where test cases translate between legacy (build/parse) and new (zerocopy fat pointers):

# ...

TPM_CC_Startup Response TPM_RC_FAILURE 80010000000a00000101
TPM_CC_Startup Response TPM_RC_CONTEXT_GAP 80010000000a00000901
TPM_CC_PCR_Read Response Success 800100000038000000000000000100000000000000010020dededededededededededededededededededededededededededededededed
# ...

something i randomly noticed in TPM key ASN.1 format:

https://lore.kernel.org/linux-integrity/aMboFXNNX7WZaOaS@kernel.org/

PoC: https://github.com/puavo-org/tpm2sh/commit/18ec3c2169b23523d8866c58fa7b8a89a79bd3d4

#linux #kernel #tpm

yay, the most complex macros, tpm_enum! and tpm_struct! have been converted to the parallel universum:

https://git.kernel.org/pub/scm/linux/kernel/git/jarkko/tpm2-protocol.git/commit/?id=4f48396e0df888ee6a5e8a2df92d71cfc05d26d8

After this it is downhill.

I'm doing this like an idiot, i.e. learning as I bump e.g., up until yesterday I was not even aware of Ref and Deref trait :-)

awesome “cast” version of tpm_enum!:

tpm_enum_cast! {
    name: TpmRcBaseCast,
    repr: TpmUint32,
    value_enum: TpmRcBaseEnumCast,
    value_repr: u32,
    variants: {
        (Success, 0x0000, "TPM_RC_SUCCESS"),
        (BadTag, 0x001E, "TPM_RC_BAD_TAG"),
        (Initialize, TPM_RC_VER1, "TPM_RC_INITIALIZE"),
        (Failure, TPM_RC_VER1 | 0x001, "TPM_RC_FAILURE"),
 // ...

I think zerocopy semantics goes to the level of implementation that using 3rd party crate like Google's "zerocopy" is essentially a PoC quality solution.

I could implement e.g. tpm2-protocol by using that as dependency but never could reach optimal results for the underlying data.

And this is how it works:

let (ref, tail) = TpmsClockInfoCast::from_slice(bytes);
let TpmsClockInfoFieldRef::clock(clock) = ref.field(TpmsClockInfoField::clock).unwrap()

Cast version TPM structures starts to shape:

use crate::{tpm_struct_cast, TpmUint32, TpmUint64, TpmUint8};

tpm_struct_cast! {
    name: TpmsClockInfoCast,
    field_enum: TpmsClockInfoField,
    field_ref_enum: TpmsClockInfoFieldRef,
    fields: {
        (pub clock: TpmUint64<'a>),
        (pub reset_count: TpmUint32<'a>),
        (pub restart_count: TpmUint32<'a>),
        (pub safe: TpmUint8<'a>),
    }
}

And after migration is completed:

use crate::{tpm_struct_cast, TpmUint32, TpmUint64, TpmUint8};

tpm_struct! {
    name: TpmsClockInfo,
    field_enum: TpmsClockInfoField,
    field_ref_enum: TpmsClockInfoFieldRef,
    fields: {
        (pub clock: TpmUint64<'a>),
        (pub reset_count: TpmUint32<'a>),
        (pub restart_count: TpmUint32<'a>),
        (pub safe: TpmUint8<'a>),
    }
}

8 KSLOC for 0.10.x branch. It would need like 100 KSLOC in C

0.11 based on smart pointer type of concept will be like 2 KSLOC less or similar figures once I finish it.

If you are C programmer and hate Rust, I'd give a shot on binary protocols. It's really objectively where Rust shines as you can easily go down to single bit level in granularity. I could never have implemented tpm2-protocol in C or even C++, it's simply out of the territory. This project has been for me like "OK, I can cope with this" type of project.

super hooked into refining this type of execution flow, way too much time spent on this lol

making sense of shit now definitely:

https://git.kernel.org/pub/scm/linux/kernel/git/jarkko/tpm2-protocol.git/commit/?id=a0f2b3b7f70f6d1151a85c1fadaac5f181e09d91

I'm just learning Rust while doing, really discovered Deref and DerefMut while doing this transformation.

@Flaky sure ofc :-)

@cos Great remark ;-) Not swearing this but I recall that ext2 driver could read ext4, it's just the journal part it cannot understand.

My favorite filesystems:

1. Ext4
2. FAT (and its various upgrades)

There's no operating system that could not read them I'm aware of.

Within last 20 years I've never had a situation where I'm in trouble because my machine does not have "advanced filesystem" :-) And basing backup strategy to local snapshots, well good luck with that. I have NAS.

@lkundrak yep exactly ;-) keep calm, carry on and worship satan

@lkundrak ok except for zmodem i'm working on "bcachefs of zmodem implementations": https://codeberg.org/jarkko/zmodem2

:-)

i might continue from that to a replacement of https://en.wikipedia.org/wiki/SMODEM, which is the competitor to the pre-existing MS-DOS version of the protocol.

@lkundrak yeah, i satisfy with modest stuff like that :-) i like most of the time sofware to do that does not exist rather than replacement for software that already exist. kent can do the god mode replacement afterwards

@lkundrak sounds like it's for smarter people than me, i would not pass the IQ test to become a legit power user of bcachefs ;-) what can you do if you're born as an idiot.