In Rust programs one common theme, which is not great for optimizing memory footprint, is the heavy use of collect(). Iterators are a great abstraction exactly for the reason that you can view items as a set without having to brute force deploy them as such in memory. One area where no language paradigm can protect against is the overuse of computing resource.

One good recipe against this e.g. in a commercial setting would be to set a constraint for core components to be no_std compatible and have total artistic freedom in user interfacing parts or e.g. storage backend interfacing part i.e. only in I/O code.

Then early steps are slower but sort of investments instead of debt when memory is considered early on…

There’s little gain with the added complexity of Rust to something like Go if this consideration is not done. Sometimes something like Go could do even a better job because then at least garbage collector considers memory constraints..

#rustlang

so soon back to terminal client. given the crate i wonder if concurrent zmodem transfer and TTY session could be shared just by routing all traffic not prefixed zdle [zpad] zpad to that session. sounds so simple that i have doubts that it would work but would be easy way have them happening concurrently.

in any case a lot of complexity of serial file transfers come from the fact that clients launch an external program to take care of it. not because the overall experience could not be overallly more user friendly.

after i get my zmodem crate integrated to my serial tool, the target to go beyond that is to look into https://en.wikipedia.org/wiki/SMODEM. there's a pile of stuff that has better taken care of in MS-DOS software (Telemate, Telex, SMODEM etc.) than in the modern day linux stack, i guess i'm a serial port and modem activist :-)

Preparing for v0.1 of my #zmodem2 crate: https://github.com/jarkkojs/zmodem2/issues/9. It is heapless and has a context structure that takes less than 2 KB of memory. Not sync but sequential because I want for first version to have just correct implementation of the protocol. Works also in no_std environment.

#rustlang

I'll switch to a repo with overlay for buildroot later on, i.e. similar but heck a lot simpler layout to https://github.com/keystone-enclave/keystone/

And neither uses heap. It needs bit over 3 kB of stack in the worst case scenario so should be fairly sustainable in many scenarios.

Great my little zmodem2 crate is now supporting no_std. Not that useful yet before I have made file transfer API sequential (repeated calls, one per subpacket), or even fully async compatible (or postpone async to 0.2).

https://github.com/jarkkojs/zmodem2/commit/bc83180cacf04b5611c4068062408ef0ed75f797

also need to make unescaping a separate stage to get clean (and fast) async implementation. now that escaping/unescaping is data instead of code it factors down the complexity of the original problem to half.

sometimes the most #fortran solution is the best :-) not pretty, probably not too “rustacean” but gets the job done…

https://github.com/jarkkojs/zmodem2/commit/a4ad4508a99b66f46ab9daf0f08956c532285107

now it is pretty easy also add quirks later on without having to maintain a grazy ruleset.

#rustlang

Typography: it matters!

#KerningToo #humor #humour #typography #graphicdesign #writing #writingcommunity

November 2023 - My Linux Kernel work

"-Wstringop-overflow

Late in October I sent a patch to globally enable the -Wstringop-overflow compiler option, which finally landed in linux-next on November 28th. It’s expected to be merged into mainline during the next merge window, likely in the last couple of weeks of December, but “We’ll see”. I plan to send a pull request for this to Linus when the time is right. 🙂 [...]"

You can read the whole post here:
https://embeddedor.com/blog/2023/12/05/november-2023-linux-kernel-work/

or at least time saver

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 :-)