two fun facts about kiova and tampere:

1. last year it was 70th anniversary of twin town friendship between tampere and kiova (tampere is my hown town).
2. kiova has a street called "tampere", which was named in 2014 to celebrate 60th anniversary of friendship, which has lasted well over its "soviet origins".

my generation does not know what it is like to be at war obviously and it would be obnoxious to say that "i get it" when it comes to war at ukraine. however, we owe to our grandparents to not forget, not make compromises and generally not to be ignorant of the situation.

🇺🇦 🇫🇮

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

It's pretty limited as of today but looking at code I'd say it's on right track :-) Likely split to a separate project some day as it grows too large (like over 2 KSLOC). I guess it's first pure Rust TPM emulator trial with like legit grounds that it is built on top of.

The current feature set is pretty much scoped with kernel testing in mind. E.g., that's why I have implemented pcr-event but not pcr-extend (which can be of course done some day) :-)

The current feature set of upcoming tpm2sh 0.11. It’s quite basic but everything is tested with care and e.g., load does all the import dance for PKCS8 RSA and ECC keys without having to mess with openssl command line. I.e. single robust load command instead of:

tpm2_createprimary --hierarchy o -G ecc -c owner.txt
tpm2_evictcontrol -c owner.txt 0x81000001
openssl ecparam -name prime256v1 -genkey -noout -out private.pem
tpm2_import -C 0x81000001 -G ecc -i private.pem -u key.pub -r key.priv
tpm2_encodeobject -C 0x81000001 -u key.pub -r key.priv -o key.priv.pem
openssl asn1parse -inform pem -in key.priv.pem -noout -out key.priv.der

And generally flows are somewhat polished and will be polished further before released to not have any rough corners. Finally most of non-trivial functionality is tested against built-in TPM emulator MockTPM.

Sometime after 0.11 release I’ll add also --dry-run switch that can exercise TPM commands with the emulator before applying them to the chip.

#linux #rust #tpm

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.