from nothing to something type of commit considering zerocopy semantics:

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

now it will be downhill :-)

#linux #rust #tpm

i've finally found my preference for command line arguments in rust: argh. it's like "between the extremes". does not get in the way but neither does "overdo"

i created an experimental "slice and compose" style disk image builder just to build appropriate EFI bootable disk images for kernel testing. i might release this at some point once it "productizes"

And once the disease is spread fully, "parse" and "build" become unnecessary. Bytes are the type and "build" is `as_slice`. Most likely 0.11 size will shrink from the current 8K line to something like 5K once all of this is done. It's a pretty decent number taking into account that the care is fully self-contained with no external dependencies.

This makes me think what's really the point of using "higher level" framework like TSS2 after one has more idiomatic and easier access to the actual core architectural type ... It's pretty quick to build resource managers and stuff like that on need and per application after you have such a tool.

In some ways this does rise an existential challenge to pre-existing sofware stacks, at least to the level that I personally rather build more software around this core than have focus on getting tpm2-protocol integrated anywhere really. I have MockTPM in good progress and some pieces for tpm2-policy module. I guess you can call that an "SDK" or something.

Even tho still only "compile-tested" code the from_slice implementation in TpmList and associated iterator is enough evidence that the approach is in fact effective:

https://git.kernel.org/pub/scm/linux/kernel/git/jarkko/tpm2-protocol.git/tree/src/list.rs

Translates pretty well (from_slice is lacking some RC related checks just PoC code):

pub struct TpmRcCast<'a>(TpmUint32<'a>);

impl<'a> crate::TpmCast<'a> for TpmRcCast<'a> {
    fn from_slice(slice: &'a [u8]) -> TpmResult<Self> {
        Ok(TpmRcCast(TpmUint32::from_slice(slice)?))
    }

    fn as_slice(&self) -> &'a [u8] {
        self.0.as_slice()
    }
}

In the end of the day this is superior despite adding up a new trick to my sack of random macro hacks:

tpm_integer!(u8, TpmUint8, Unsigned);
tpm_integer!(i8, TpmInt8, Signed);
tpm_integer!(u16, TpmUint16, Unsigned);
tpm_integer!(i32, TpmInt32, Signed);
tpm_integer!(u32, TpmUint32, Unsigned);
tpm_integer!(u64, TpmUint64, Unsigned);

Now the names match TCG specification names, and they are also first fully zerocopy migrated types. This way previously redundant looking field now is actually self-documenting field.

Other zerocopy types will get the nasty “Cast” postfix up until migration is complete (e.g., TpmBufferCast).

For the record, the last field is used to address exactly one quirk related to TCG specs: TPM_CLOCK_TIME, meaning that “invalid discriminant error” needs too versions :-/

I’m sure we would get numbers going from zero to six, and “get this complex science” as e.g., most of have ability to read, and understand nuances such as the difference between slower and faster… This is DailyWTF proximity enough level bad definition that I tend to like that TPM_CLOCK_TIME exist…

Great now I think I have solid base traits in place i.e., TpmCast, TpmCastMut, TpmHasCast and TpmHasCastMut:

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

I also relaxed the contribution guidelines just a little bit:

 //! * `alloc` is disallowed.
 //! * Dependencies are disallowed.
 //! * Developer dependencies are disallowed.
-//! * Panics are disallowed.
+//! * Panics are allowed disallowed by default, except concrete type casts in
+//!   `TpmCast::as_slice` is allowed to use `unwrap` as long as
+//!   `TpmCast::from_slice` meets the documented contract.

In various situations ability model RS-232 link for testing tools that e.g., access FPGA is an asset.

What would be a simple stochastis model that I could apply to my serial link emulator to add "realistic line noise", and don't have climb mountains to implement the algorithm?

With Rust I find the old (non-neo) vim still the most efficient text editor especially wtih complex macro declarations the static nature of the editor is an advantage.

Modern IDEs feel like ransomware. They completely destroy the screen when there's like one punctation mark missing or something and only thing that auto-complete accomplishes for me is the lost focus on task.

I tried in Sublime Text with Copilot only because Microsoft provides me a free pro license for it and it was even worse than normal autocomplete given it's wrong and fallible suggestions that completely destroy focus. I just wanted to see what it is like and it was piece of shit tbh.

Rust macros are actually a bit like "autocomplete all my objects with traits" type of tool where you write a recipe on how to auto-complete.

@cehteh sorry if I was a bit rude in my first response, i'll definitely checkout usynn once i have a chance :-) (not just saying that for plain politeness/ignorance).

@cehteh The protocol crate is in the process of scraping parsing completely as it parsing has a memory cost (it produces an object to stack) :-) But yeah, I'll check it out for expression parser once I get into doing tpm2-policy. I'm not really sure how I'm going to scope that yet.

There is a unfortunate parse which will be addressed by "migration helper trait" HasTpmCast in the follow-up commit. That is the first across the board zerocopy change.

or actually i might use some dependencies for tpm2-policy but have not decided on that so i keep it in mind :-) generally i don't prefer external dependencies as they don't translate to bootloaders, firmware and kernel.

@cehteh absolutely not, see https://git.kernel.org/pub/scm/linux/kernel/git/jarkko/tpm2-protocol.git/tree/src/lib.rs

still as relevant song as it was in 2014 ;-)

https://www.youtube.com/watch?v=NWxISwEBU0U

Great landed kickoff commit for casting TPM data to the main branch:

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

@Dr_Emann, and yep:

- ($ty:ty, $variant:ident) => {
+ ($ty:ident, $variant:ident) => {

EDIT: extended further to lists (and commit ID above updated) as TpmList was a pretty good test case for the trait definition itself. Luckily I had used PhantomData a few times when contributing to Enarx few years ago so I was able to make this stretch :-) Now I have like the baseline for doing zercopy in place.

This starts to “feel right” when it comes to “zerocopy”:

pub trait TpmCast<'a>: Sized {
    fn cast(slice: &'a [u8]) -> TpmResult<Self>;
    fn as_slice(&self) -> &'a [u8];
}

And pretty analogus to pre-existing TpmBuild and TpmParse i.e., they provide clone semantics and this is like hierarchical pointer.

It’s pretty easy to squeeze in because I only really have to edit macros for the most part. I have already basic types, and buffers and lists will follow the same patterns.

@cehteh yeah i know :-) i might try GNU make proc macro compilation for the sake of experiment at least. in tpm2-protocol i have everything building with make including all test programs: https://git.kernel.org/pub/scm/linux/kernel/git/jarkko/tpm2-protocol.git/tree/Makefile.

For this crate per se I think procedural macros would be a bad idea, it is good as it is but I might give them a shot in a crate called "tpm2-policy", which uses tpm2-protocol to create expression language for policies.

@Dr_Emann OK I tested it and it looks like it is true. Thanks for the great remark!

Still leaves me a bit confused tho of when the "real" ty fragment is the only working option