core::array::from_fn is a life-saver #rustlang

My #kernel (smoke) #testing ground: https://github.com/jarkkojs/buildroot-tpmdd

I think it is useful enough also update to MAINTAINERS. I’ve also tweaked #qemu scripts to automatically put #swtpm on background and some options what sort of TPM ought to be emulated.

#buildroot #linux

@almenal99 i have no strong opinions on text editors, which is probably obvious already since i switch it every 10-20 years at most :-) it feels to me like discussing whether bosch or makita is superior if i was doing renovations sort of...

@mo8it yeah, exactly. this was getting too insane :-) i liked vim the most when it did not have many plugins... then it also did not matter much which vim version happened to be around.

Started this just a bit over a week ago and circa 90 commits done :-) I desperately need this myself and the stack has been a trainwreck for literally decades, and far behind what MS-DOS provided, which is a disgrace...

Learned how async works in Rust and it looks like straight-forward to convert #zmodem2 crate to that as I have state machine alike structure for both send and return. Given how slow these transfers I make it async only, not async opt-in feature.

After that only some minor things need to be added and fixed and I can finally start gluing it to https://github.com/jarkkojs/tior and start working on its UI again.

For tior I’ll switch also switch to serial2 crate, which provides simpler API, a pro-active maintainer and fully working Windows serial support, which is not the case with seriaport.

With the asynchronous ZMODEM crate (right now the standard is invoking external program) it is possible to implement file transfer dialog, which shows progress, cancels the transfer according to the specification and generally not get a feeling that system is somehow halted :-)

Hope everyone noted that I used words "mitigate" and "decrease", not e.g. "address" or "protect from" :-) Security is (and always has been) all about making breaking in expensive and visible enough to the level that the price is too high than the value of the asset protected. It is not that much different from physical world where you decide which sort of locks, doors etc. your house needs so that no one wants to rob your property.

James Bottomley posted new version of the #HMAC encryption patches for #TPM2: https://lore.kernel.org/linux-integrity/20231127190854.13310-1-James.Bottomley@HansenPartnership.com/T/#t

I spent some time refactoring the tpm_buf changes because they were the major glitch for me in the earlier versions, and those patches have been included now to this series, which is of course great. The series is probably rather sooner than later ready for inclusion to the mainline.

This adds up to the TPM2 sealed hard drive encryption by mitigating bus interposers by a factor. An interposer is an actor intercepting traffic between the CPU and a discrete TPM chip (i.e. not firmware TPM).

A bus interposer can reset a TPM and replay PCR’s as the chip returns to its initial state, which resets them. To mitigate this, kernel creates HMAC session for each TPM transaction and derives session key from the so.called null hierarchy, which essentially provides a new random seed per TPM reset.

Therefore, interposer’s ability to reset TPM decreases because kernel will not be able to communicate with the TPM and that way indirectly a malicious act can be detected by far better chances than ever before.

IMHO, this fits quite nicely to the stuff that #OpenSUSE and #Ubuntu have been working on lately.

@occhiolist sure np :-)

@occhiolist TBH, I had to do a web search to find out what systemd-homed even is :-) So I guess I don’t possess that information.

My guess is that systemd-homed should not need to support at least when having LVM on top. User space is unaware that there even is encryption for the most part (except tools that specifically communicate with firmware/UEFI/MOK for e.g. grabbing a recovery key). For me it is pretty hard to make a corner case but I don’t have hard data. on this one. Hope this helps.

I use now #TPM2 sealed LVM/LUKS2 encrypted partitioning in my Linux desktop. No need to type password anymore when booting up great. #Linux #TPM

I switched to #helix editor because three advantages weight me more than disadvantage of having to learn away for #vim shortcuts:

1. Too much legacy.
2. Too many plugins.
3. It is a varying challenge to install the latest version #neovim, which anyway needs to be done in order not to break init.lua (and that big pile of plugins).

So for the price of few weeks inconvenience I can stop spending time on text editor configuration and/or figuring out on how to install it.

I used #vim and later on neovim fo the period 1998-2023, even before using Linux. I switched to vim in MS-DOS from text editor called #QEDIT :-)

Does Rust #Linux already have bindings for network drivers? I’m thinking of making #lowRISC Ethernet driver because the one provided by OpenHW Group is a corpse. It is like made for v5.7 and since not updated. This is the one that is used in #CVA6.

#rustlang

I think I fixup lookup tables for escaping #zmodem traffic by intercepting traffic from lrzsz with “defacto” parameters, i.e. send large chunk of uniform distributed random data. That way I can be sure that I have all the cases, including those not in the specification form 1988.

Later on I can use that as a CI test for my crate. Sort of fuzzing approach. I just need to record all bytes that follow ASCII 24 and that builds my table.

nice that #github allows to turn off issues, if only "pull requests" could also fully disabled #microsoft

I’ve been using Rust professionally way or another for about 2 years now and at least this and also lack of e.g. BufRead abstraction (sorry trait) has been something that I’ve been cursing to this day because it enforces you to do totally unproductive boilerplate and glue for everything you do with Rust. So definitely a huge improvement is this… Doing some RidiculousError type for every no_std thing is just terrible IMHO. For 95% of stuff I’d rather use just predefined error codes. It also improves productivity by factors when all your crates communicate with same error codes.

Abstraction only ever make sense if they have some meaningful functional use. Otherwise, they are just code bloat.

@ukuli ei mua ihan kauheasti kiinnosta sannan asiat :-) lähinnä kiinnostaa oman elämät ilot ja surut. live and let live ja näin päin pois...

embedded-io and embedded-io-async seem to be something i would want to use also for crates meant to be used with std just to future-proof portability. great that there is solution for std::io issue finally. for me the disability to e.g. not being able to use std::io::Error in no_std code has been a huge turndown.

and since these are provided by the Rust HAL team there’s some trust for long-term lifespan. 3rd party solutions in the basic error types and BufRead is a maintenance risk imho.

this is good enough as far as i’m concerned

#rustlang #embedded

@monsieuricon just like netflix used to work as a postal service

Little known fact: first kernel releases were shipped via the postal service.