Jarkko Sakkinen
Posts
4941Following
327Followers
492OpenPGP: 3AB05486C7752FE1
@diondokter
[I edited the message had to think a bit what I meant.]
OK so, this would stdcall in C:
int __attribute__((__stdcall__)) foo() { asm(" ...
This would be naked stdcall
__attribute__((__naked__)) int __attribute__((__stdcall__)) foo() { asm(" ...
So you're correct saying that in naked version you do what you want but the difference is that you're telling GCC that "I will use stdcall". This makes the function compile equally well in Linux and Windows.
GCC won't create epilogue and prologue for you but it will make the assumptions based on stdcall how you've organized the function from callers perspective. I don't know how to do this in Rust.
[I edited the message had to think a bit what I meant.]
OK so, this would stdcall in C:
int __attribute__((__stdcall__)) foo() { asm(" ...
This would be naked stdcall
__attribute__((__naked__)) int __attribute__((__stdcall__)) foo() { asm(" ...
So you're correct saying that in naked version you do what you want but the difference is that you're telling GCC that "I will use stdcall". This makes the function compile equally well in Linux and Windows.
GCC won't create epilogue and prologue for you but it will make the assumptions based on stdcall how you've organized the function from callers perspective. I don't know how to do this in Rust.
1
0
0
Jarkko Sakkinen
repeated
repeated
pHinnWeb
phinnweb@ravenation.club[video] Blastromen (a.k.a. Sami Koskivaara & Mika Rosenberg) - Live @ Hellsinki Industrial Festival, Tiivistämö, Helsinki, Finland, 8 November 2024.
https://www.youtube.com/watch?v=g10owNrqthA
#Blastromen #electro #electronic #DominanceElectricity #HellsinkiIndustrialFestival #SamiKoskivaara #MikaRosenberg #Tiivistämö #Helsinki #Finland
0
2
0
Jarkko Sakkinen
repeated
repeated
Behind The Console
behindtheconsole@podcasts.social
Edited 2 months ago
Real or @NanoRaptor #datArena
Well this an IBM 5120 https://en.wikipedia.org/wiki/IBM_5120 a preliminary system to the IBM PC.
1
2
0
Jarkko Sakkinen
jarkko
Very cool, I start to participate to tpm-rs meetings :-) My project is not a conflicting entity, it's just the protocol layer isolated and made for import (a design choice driven by kernel ofc).
I was just worried what are the thoughts when I come from the woods and say that here's 7000 lines of source code, please repeal and replace but initial feedback is actually quite positive.
For kernel (and tpm-rs) if/when kernel has TPM2 support on Rust side the model could be a bit similar as it is for ACPICA. You have a fast policy-free upstream that tracks the protocol spec as it develops and import cycle.
Would be great to see tpm-rs story to continue but obviously they make their choices.
I was just worried what are the thoughts when I come from the woods and say that here's 7000 lines of source code, please repeal and replace but initial feedback is actually quite positive.
For kernel (and tpm-rs) if/when kernel has TPM2 support on Rust side the model could be a bit similar as it is for ACPICA. You have a fast policy-free upstream that tracks the protocol spec as it develops and import cycle.
Would be great to see tpm-rs story to continue but obviously they make their choices.
0
1
1
Jarkko Sakkinen
jarkko
@teotwaki not for all projects but for basic protocol implementations that you want translate to any environment, it's really useful to focus on this type of robustness.
E.g., for zmodem2 I'm redesigning it as something that walks and talks stream trait implementation but is not such [1]. Then in my example apps I'll migrate them to Tokio and demonstrate how to wrap it for that use and purpose.
With traits, when I use them, my strategy is usually pick stuff that gets the first iteration done fastest. Then I start to drop over time stuff that maturizes and keep only the essential traits. If you have stable code, the benefit of productivity in the first phase starts to degenerate into something that can get in the way of bug fixes etc.
[1] https://docs.rs/futures/latest/futures/stream/
E.g., for zmodem2 I'm redesigning it as something that walks and talks stream trait implementation but is not such [1]. Then in my example apps I'll migrate them to Tokio and demonstrate how to wrap it for that use and purpose.
With traits, when I use them, my strategy is usually pick stuff that gets the first iteration done fastest. Then I start to drop over time stuff that maturizes and keep only the essential traits. If you have stable code, the benefit of productivity in the first phase starts to degenerate into something that can get in the way of bug fixes etc.
[1] https://docs.rs/futures/latest/futures/stream/
0
0
0
Jarkko Sakkinen
jarkko
@teotwaki https://github.com/puavo-org/tpm2_library/blob/main/Makefile
Of course for apps I use crates but on those I also tend to dilate towards less cluttered abstractions (e.g., i prefer json crate over serde_json). That is what I use in tpm2sh.
This another project I'm working on which does not have dependencies: https://codeberg.org/jarkko/zmodem2. For this there's no priority to do Makefile for CI as it does not target for Linux kernel.
Of course for apps I use crates but on those I also tend to dilate towards less cluttered abstractions (e.g., i prefer json crate over serde_json). That is what I use in tpm2sh.
This another project I'm working on which does not have dependencies: https://codeberg.org/jarkko/zmodem2. For this there's no priority to do Makefile for CI as it does not target for Linux kernel.
1
0
1
Jarkko Sakkinen
jarkko
IMHO, good design goals for any Rust crate would be that:
1. It should run on your toaster.
2. It should run on #Amiga.
Once I stopped using Cargo and 3rd party crates when making my own crates I've started to enjoy Rust for real :-) IMHO, programming should be fun, not efficient or "productive". If I have to start to be too efficient I'll immediately stop this career.
#rust
1. It should run on your toaster.
2. It should run on #Amiga.
Once I stopped using Cargo and 3rd party crates when making my own crates I've started to enjoy Rust for real :-) IMHO, programming should be fun, not efficient or "productive". If I have to start to be too efficient I'll immediately stop this career.
#rust
1
1
9
Jarkko Sakkinen
jarkko
My next thing in the Rust world is Z-modem but beyond that I'm also looking into legendary S-modem after I get Z-modem first in shape:
https://en.wikipedia.org/wiki/SMODEM
Back in the day S-modem enabled to download your games and porn, and chat with the sysop while doing it ;-)
#bbs #zmodem #smodem
https://en.wikipedia.org/wiki/SMODEM
Back in the day S-modem enabled to download your games and porn, and chat with the sysop while doing it ;-)
#bbs #zmodem #smodem
1
1
5
@Netux It has been for me problematic to understand why we care about Rust because trivial memory errors are not something we would need a whole new language ecosystem. It's really this ability compose/decompose data that matters in Rust for kernel IMHO. In quite many categories of drivers it would take them to the next level if they could look more than just "max length" or similar attributes. Wanted to write it down while I had the thought on my mind :-)
1
0
1
Jarkko Sakkinen
jarkko
Now it is time phase out doing this and detach myself from the grip of hyperfocus ...
https://lore.kernel.org/rust-for-linux/aKUTF6lu5JetDJxX@kernel.org/T/#u
Ton of stuff that I did not do during last three weeks that I should had done (mainly outside of work) so navigating myself to that direction :-) I just could not stop, once I got really started.
Also I sleeping might be good idea once in a while :-)
#linux #kernel #tpm #rust
https://lore.kernel.org/rust-for-linux/aKUTF6lu5JetDJxX@kernel.org/T/#u
Ton of stuff that I did not do during last three weeks that I should had done (mainly outside of work) so navigating myself to that direction :-) I just could not stop, once I got really started.
Also I sleeping might be good idea once in a while :-)
#linux #kernel #tpm #rust
1
1
5
Also this CoC code creates literally enclaves (pun intended) of code to arch having very low chance to get reviewed with the same standards as other non-CoC arch code, given that there is a low number of maintainers with ability to run it.
And even those maintainers who can run it usually have no local hardware but instead have to use some company internal cloud, given how expensive hardware is and also the form factor (noisy power eating server rack) is dysoptimal for devs to begin with.
SGX is not as bad as SNP or TDX given that it is based on memory pages instead of virtualization and this is consolidated to its own driver, but even SGX is practially inaccessible for most and AFAIK there's no official QEMU emulation for it (shame on you Intel).
TEE based on VM (SNP, TDX) is IMHO a broken security concept to begin with but that's another topic.
And even those maintainers who can run it usually have no local hardware but instead have to use some company internal cloud, given how expensive hardware is and also the form factor (noisy power eating server rack) is dysoptimal for devs to begin with.
SGX is not as bad as SNP or TDX given that it is based on memory pages instead of virtualization and this is consolidated to its own driver, but even SGX is practially inaccessible for most and AFAIK there's no official QEMU emulation for it (shame on you Intel).
TEE based on VM (SNP, TDX) is IMHO a broken security concept to begin with but that's another topic.
0
0
0
Jarkko Sakkinen
jarkko
12000 SLOC for full TCG TPM 2.0 protocol spefication in three weeks (with about 1000 SLOC of initial code I made year ago).
This includes also tpm2sh. The protocol crate is only ~7000 SLOC.
Now that tpm2_protocol is "complete", I'd believe that it will also slim down over time because first version always the fattest.
I think tpm2_protocol would be the right basis for Linux Rust support for TPM2 but it definitely must mature some time so that low-hanging bugs etc are fixed.
tpm2sh is still quite immature but it is just a test program :-) It has quite a lot of crypto code but use that your own responsibility. I've added that to help with testing now meant for use in production.
#linux #kernel #tpm #rust
This includes also tpm2sh. The protocol crate is only ~7000 SLOC.
Now that tpm2_protocol is "complete", I'd believe that it will also slim down over time because first version always the fattest.
I think tpm2_protocol would be the right basis for Linux Rust support for TPM2 but it definitely must mature some time so that low-hanging bugs etc are fixed.
tpm2sh is still quite immature but it is just a test program :-) It has quite a lot of crypto code but use that your own responsibility. I've added that to help with testing now meant for use in production.
#linux #kernel #tpm #rust
0
0
0
Jarkko Sakkinen
jarkko
Well... hell... TCG TPM 2.0 specification 184 minus one command coverage.
2
0
0
If you read what FSF has said about TPM over the years, a lot of it applies exactly to confidential computing.
Also they lock-in to company CA meaning that:
1. AMD, ARM or Intel can brick your hardware.
2. If they decease the business, your hardware will be bricked.
Also they lock-in to company CA meaning that:
1. AMD, ARM or Intel can brick your hardware.
2. If they decease the business, your hardware will be bricked.
1
6
8