@lindi2 Cool to hear! And please contact me if you find something. I'd expect at least some issue, if not security, then stability but that is obviously to case for any code that has not yet been in the warzone, right? :-)

So, yeah it *should*. It uses null seed for TPM key generation which is shuffled per power on and creates HMAC pipe to the TPM which is unconditonally applied to the user space devices. also it denies comms if the null seed is resetted.

Also the stuff @pid_eins and systemd folks have been working is expected to not be "warzone ready" ;-) some social of the media feedback on that has been somewhat uneducated (not referring to demo videos, it is helpful the demonstrate the issues and open source by definition should be brutally honest and transparent).

@pinkforest @calbaker @laund

@pinkforest thanks for great comments!

talking about asm, one feature i’m waiting for to become stable is naked functions, which is fortunately in unstable.

one api that was outdated even when rust first came out is File API. it models POSIX golden days of the tape drive part ;-) i.e. it is pretty much in the 70s idiomatically. or what was the latest thing back then.

with modern storage and 64-bit address space only thing that you ever want to use fd for is with sendmsg(SCM_RIGHTS) when you share it betwen multiple processes.

rest is better to be done simply by mapping the whole thing to address space and let page cache take care of you. initially reserved set size is ofc zero bytes with invalidated page table entries.

it is great way to also deal with large sparse arrays for the obvious reasons.

not a huge issue. i’m pretty happy with https://github.com/rust-vmm/vm-memory but hopefully stdlib will have equivalent functionality some day. despite the name this can be used outside KVM context.

@pinkforest @calbaker @laund Not pointing fingers to any particular community, project or even language but here's something I observe in modern days of open source.

There has been and probably is still today some toxic behavior for sure in open source projects but there is also some toxic positivity, which means that when you take more critical angle it is interpreted as toxic behavior.

@pinkforest @calbaker @laund Also, of course Rust helps to do that authentication module properly but part of it is also me making legit choice how I use Rust to achieve my goals. Not disregarding the merits just calling for more critical thinking :-)

@pinkforest @calbaker @laund Nothing wrong in Perl tbh. Any language, even Rust does not prevent you from making trainwreck code tbh :-)

@pinkforest @calbaker @laund I tend to agree with this. I mean if you add a dep to Cargo.toml to get rid of unsafe block that is actually needed there is still unsafe block somewhere. It is just not visible in your own crate :-)

Rust 1.78 makes especially putting some trivial unsafe blocks easier and more plausible with its assertion features: https://blog.rust-lang.org/2024/05/02/Rust-1.78.0.html

@pinkforest @calbaker @laund Yeah, I've seen in my work that trying to be as "case by case" as possible is an asset in software industry. Even your favorite tools is best tool look with critical eye from time to time :-)

@pinkforest @calbaker @laund

I get that for sure but…

This is the thinking that apply 100% also to any piece of user space code that I might do. I figure out the best possible solution that I can think of with my limited skills and then pick the tool that I try to nail it sometimes succeeding and sometimes failing. So yeah, my world is as plain and simple as that :-) Engineering problem at hand is the first priority, and obviously to pick the right tool I need to exactly compare pros and cons of them for that particular problem.

A recent example is an authentication module prototype that I’m developing for Ethereum ecosystem (and presenting possibly at ethprague). For that I’m most likely using Rust, and ended up to that outcome by comparing pros and cons of possible alternatives.

@pinkforest @laund @calbaker The core skill in engineering is to solve a problem and call it day in my books :-)

C and Rust are just tools that you might want to apply, and picking the right one based on a careful analysis of the problem at hand is the core skill, at least of an engineer.

There's as much confrontation between C and Rust as there is between a screwdriver and a chainsaw. I don't know what having a core skill in language even is other than understanding its syntax and semantics.

I'm not part of any weird "cult of C" so cannot really say that I would be part of this "C. vs Rust" confrontation. I just do stuff plain and simple. Whatever works, works. I.e. I don't have "a tool based identity".

Calling Rust as a feature is like calling cooking recipe as a spice or ingredient in a dish, which has no logic.

I don’t know how advisable this is but it did the job 🤷

git filter-branch --msg-filter 'cat - && echo "Signed-off-by: Jarkko Sakkinen <jarkko@kernel.org>" "$@";' HEAD~22..HEAD

#git #note

Great, #TPM bus protection is ready to be applied: https://lore.kernel.org/linux-integrity/D10E68XSE1FV.1XZL0Z6TV7DWX@kernel.org/

@laund @calbaker so you could then use the best phrase ever in English language: agree to disagree ;-)

vm-memory is really cool and should be IMHO part of stdlib :-) best way to map files and other memory so far in #Rust.

Some project types where you absolutely need memory mapped I/O are:

• Operating Systems
• Database Management Systems
• Virtual Machine Managers
• Game Engines
• Digital Audio Workstations

I.e. anything with high scalability, high availability and in real-time processing low latency.

#rustlang

@ljs Thanks mate! Yeah, and I thought that if this makes anyone feeling bad of not doing the exercise, it is actually good :-)

Week #2 lifting weigths done after two year break. Since I have to post this, it is not a routine yet 🙂Feeling better than in ages and peace in mind. #detox

@laund @calbaker ok cool, i'm fine with being stupid beyond the scope of "none yet" ;-) no reason to get upset tbh.

@calbaker @laund E.g. it is proved that the problem of "zero bugs" cannot be proved except when you have some well defined constraints which is basis of formal verification. In generic case, i.e. Rust app ecosystem we are talking numerically infinite set of programs with no constraints except those that computational model of Turing machine sets.

@calbaker @laund It is pretty weird to see comments that fight against lemmas that have been proved by computer science decades ago. As if Rust was yet another computational model, e.g. in same level as turing machines and quantum computation.

@calbaker @laund Yeah, Rust is great and for any non-legacy fresh new project that I had previously written in C or C++ I would pick it any day.

It just that I consider it harmful thinking that problems are solved by tools. Rust can bring the edge but it needs to be supported understanding its shortcomings, limits, CPU architecture, binary formats (ELF, COFF/PE) and various other domain assets. Rust alone is not a problem solver. So it is important to raise attention on this issue.

Huge issue in #riscv specifiations is the lack of pseudocode. E.g. this is from the description of SWI opcode:

"The Wait for Interrupt instruction (WFI) provides a hint to the implementation that the current hart can be stalled until an interrupt might need servicing. Execution of the WFI instruction can also be used to inform the hardware platform that suitable interrupts should preferentially be routed to this hart."

Any ideas what actuallly happens when WFI is executed? I don't know. For x86 I just find the opcode from Intel SDM, and then I just read the pseudocode. I usually do not even read the prose unless really need to get bottom of it.