does any of the ext4 crates for rust *initialize* a partition? I don't care of being able to read or write it, only "mkfs" part is interesting.

no SIZE constant anymore in the new TpmSized as no stack allocation is required:

/// Provides a `dyn`-safe way to get the exact size of a zero-copy cast object.
pub trait TpmSizedCast {
    /// Returns the exact serialized size of the object.
    fn len(&self) -> usize;

    /// Returns `true` if the object has a serialized length of zero.
    fn is_empty(&self) -> bool {
        self.len() == 0
    }
}

This ought to be renamed as TpmSized as full migration is over :-) Applies also to all other *Cast.

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"

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

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.

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.

Another more fun Rust related activity is figuring out how to nail batch file transfer test planning with emulated serial port that throttles the speed to a target BPS (in future also should have also signal noise emulation):

const ADJECTIVES: &[&str] = &["Quiet", "Loud", "Fast", "Slow", "Bright", "Dark"];
const NOUNS: &[&str] = &["One", "Two", "Three", "Four", "Five,", "Six"];
const EXTENSIONS: &[&str] = &["dat", "BIN", "log", "TMP", "txt"];

struct MockPort<R: Read, W: Write> {
    r: R,
    w: W,
    bits_per_second: u32,
    next_byte_due: Instant,
}

It generates 10 pseudorandom filenames and 100 KiB payloads.

Just solved a Rust sudoku for the next version of tpm2-protocol

I think this is quite clever trick to surpass some of the limitation of syntax tree macros:

macro_rules! tpm_integer {
    ($ty:ty) => {
        pub mod $ty {
            #[derive(Clone, Copy, Debug)]
            pub struct TpmView<'a> {
                pub slice: &'a [u8],
            }
        }
    };
}

Further, TpmView implements a trait called TpmView. This circulates around limitation that type cannot be used to name things in syntax tree macros.

Otherwise, unless moving into procedural macros, I’d end up ugly declarations along the lines of:

tpm_integer!(u8, TpmViewU8, Unsigned);
tpm_integer!(i8, TpmViewI8, Signed);
tpm_integer!(u16, TpmViewU16, Unsigned);
tpm_integer!(i32, TpmViewI32, Signed);
tpm_integer!(u32, TpmViewU32, Unsigned);
tpm_integer!(u64, TpmViewU64, Unsigned);

Transparency has been the single biggest blocker in moving forward with zerocopy parser and this sort of “nails it”.

EDIT

I was wrong in that you could type as module name. However, the trick does still resolve the name coflict with the original type and view type. The minor inconvience of having to repeat it twice is totally acceptable vs having to manually name stuff:

tpm_integer!(u8, u8, Unsigned);
tpm_integer!(i8, i8, Signed);
tpm_integer!(u16, u16, Unsigned);
tpm_integer!(i32, i32, Signed);
tpm_integer!(u32, u32, Unsigned);
tpm_integer!(u64, u64, Unsigned);

This is absolutely sustainable for me :-) I.e. second parameter is name of the module.

Here’s a working proof of concept: https://git.kernel.org/pub/scm/linux/kernel/git/jarkko/tpm2-protocol.git/commit/?h=zerocopy&id=42f61d9d85e17f784f71c8ac64ee6adbb7171997

#rust #rustlang

zmodem2 0.1.4 release with split subproject "zmodem2-bin" (cargo install zmodem2-bin).

#rust #zmodem #tty #serial

The policy module in tpm2sh is growing enough meaning that I will eventually fully decouple it and introduce 'tpm2-policy' crate.

Just like tpm2-protcol, this is a mailing list project and will be hosted at git.kernel.org.

'tpm2-policy' provides an expressive language for policies and can additionally "open code" input expressions e.g., set actual values for PCRs (if they are unspecified and digest is composed it queries them from TPM).

It can compose digests both via means of TPM2_Policy* command but in addition is capable for software composition (not yet landed tho but coming soon ;-))

The big picture design principle in this crate is, just like in tpm2-protocol, that it scales both to client use, and at the same time software composition engine is capable of empowering TPM emulator or even a real chip.

#linux #rust #tpm

In tpm2-protocol, extended "response round-trip" test to understand crate's error codes with the worst parser ever written:

0176 Success 80010000002000000000800200000010bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb
017E TrailingData 800100000038000000000000000100000000000000010020aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaadeadbeef
0144 NotDiscriminant("TpmSt", Unsigned(0xffff)) ffff0000000a00000000
0176 Success 80010000003000000000030000000020ab967bc21b9c90096051d1e0f0dbfb29fc27258b03705fbc0c40aaaac88ed5e5

This also helps to better understand whether the pre-existing error codes make sense, how they should be modified, what should be added/removed etc. in the future versions of this crate.

There's no separate "pcr-read" command anymore in tpm2sh as policy command is robust enough to address that task too:

❯ sudo target/debug/tpm2sh policy "pcr(sha256:0,7)"
pcr(sha256:0,7, 9c367f8c268d51ced151a664d88e37e74fcd84485eff8ff9bc26d22aa9091020)

With --compose flag it creates the policy digest.

The goal in in tpm2sh 0.11 is to repeal and replace the pre-existing uses of tpm2-tools to enable things like PCR sealed hard drive encryption. I'm focusing on smooth and for a sysadmin type of a person common sense type of flow.

It's more like UI problem than a technical problem. A great cli is such that you can put it powerpoint sheet and everyone will get it down to reconfiguring your computers.

#tpm #rust #linux