@lorddimwit Nothing against Zig but we apparently chose Rust.

I still think we should fork Rust and strip it down like hell. Then it would not be compatible with Rust but more like relative. I don’t see any problem in that I mean even C is not at least formally a subset of C++, they have some differences in semantics

I don’t care about languages (except little bit of C which is lingua franca for ABI) but I’m more like worried:

1. Experienced maintainers in file systems, mm etc. with no time at hands are not able to do proper analysis on Rust. So we are going to the unknown without “shared consensus” being on the steering wheel.
2. It has tons of “never use this in kernel” crap, which we IMHO should just remove from it. Who care if we end up something NOT Rust but still relative or similar to Rust.
3. Language spec is out of control… and in Github ;-)
4. Compiler bugs are a disease. That huge ever growing language spec maintains their steady flow.
5. It will be tedious job to maintain correspondence with gccrs and rustc. Even if you think that LLVM should be everywhere (which is no-go for linux but just for the sake of example), how do you do ever detect all those nasty compiler bugs?

We need something more compact that does not change often so that also compiler’s implementation can be matured, bugs fixed etc. So yeah, to sort out this madness I really do personally (this is my voice only, not korg as org) think that we should stop this madness and just do a fork and control all that in kernel mailing lists. Linux would deserve language of its own, relative to Rust but not always compatible…

@leeloo @vathpela

Yes all that crap piles up to put short. Read about binary analysis, compilers, linkers, ELF ABI specs etc. and you should get a grip.

If Windows XP was released in 2024

@kornel Traits and generics would still need some mangling but limiting their features we could possibly get the symbols in the ELF binary have names that would be more familiar and meaningful and more C alike instead of following C++ convention like Rust does. Right and I think unwrap() should not exist as any default behavior is harmful, especially panic. So yeah there would be lot of stuff that could be simply wiped away and get a better language for kernel dev.

@kornel We could keep the features from Rust that make sense ofc and remove those that don’t and get a tighter language spec which is less prone to often ignored compiler bugs when discussing about safety properties. By freezing the language with a fork of Rust, it would be also easier to keep ”lustc” and ”gccls” in sync (if the fork was called ”lust” for the sake of example).

@kornel well for kernel we need only fallible allocations, namespaces could be taken away (and causes need for symbol mangling), no use for external crates, we don’t use cargo because vmlinux is self-contained, we don’t use rust’s atomic type. There’s alot of harmful features in Rust for kernel. Just randomly picked a few.

The worst part of any trip ongoing: departing home. The best part of any trip is yet to come: arriving home. ✈️

@vathpela Oh, and then we could run the development of language spec and the compiler frontends in total three mailing lists (e.g. lust-lang@vger.kernel.org, lust-gcc@vger.kernel.org and lust-llvm@vger.kernel.org).

Github makes following the language development with easy ways to backtrack years old discussons almost impossible or you really have to put effort to it vs. just going to lore and grabbing a mbox.gz of a relevant discussion.

I really wish I would live in this nice and lusty alternate reality instead of this crappy and rusty reality ;-)

A plea for more thoughtful comments https://lwn.net/Articles/975597/ #LWN

Here are the slides for a talk I just gave about using perf c2c to find cache line contention in postgres:
https://anarazel.de/talks/2024-05-29-pgconf-dev-c2c/postgres-perf-c2c.pdf

@vathpela And yeah C and Rust would be by definition bridged then. And language would be still familiar enough that knowledge of Rust would help to cope with it.

@vathpela There's only like 50-60 Rust files in total in the mainline so it would not be even tremendous job to initiate. Not whole a lot of legacy, and all of it is experimental features (e.g. given the lack of gccrs support cannot be turned on in arch defconfig).

@vathpela You could even ironically say that it would be Rust way of approaching open source: fork anything in existence and make Rust version out of it. Like even coreboot has a version called "oreboot"

@vathpela It might be.too radicalized thinking but sometimes I feel that maybe Linux should simply fork Rust and remove unnecessary stuff. We in any case do not want external dependencies for vmlinux so it would be for the most part just stripping of features. By removing e.g. namespaces we could simplify the equation of getting rid of name mangling. Also then there would not be a problem of having incompatible atomic, which applies actually both C and Rust.

And right, then the language could only have fallible allocations, not just as an additional feature but instead as an enforced pattern.

Not my decision but I do have right for an opinion at least. Let's call this fantasy language as Lust ;-)

@vathpela Yes, that was a rough cut, skipped relocations, GOT, PLT etc. ;-)

I think there would be still space for systems programming language with a constraint from day zero that it would 1:1 compatible with plain C”s binary layout and memory model:

1. Roughly just .text, .bss, .rodata and ,data.
2. No symbol mangling at all.

All the memory safety etc. fancy features would be then designed within exactly those constraints.

#Rust is essentially a derivative of C++ when compiled to binary, which does not really make it a strong competitor for plain #C. It can substitute C in many cases for sure, just like C++ did, but there’s always need for minimal systems programming language, which also looks elegant in binary, not just in source code.

A compiled C program can be quite easily understood with a binary with no debug symbols at all if you understand the CPU architecture well enough. That is, and will be a strong asset for C.

#cplusplus #rustlang

My game plan for the next weekends Ethprague is this:

1. Introduce roles in authentication: user and machine both I think should be represented with their own private keys. I.e. consider ENS as a fancy LDAP that the machine can access.
2. Represent asymmetric TPM2 keys (tpm2_key_rsa, tpm2_key_ecdsa) as a way to give a guarded identity for the machine (or node).
3. The lack of TPM_ECC_P256_K1 in TCG Algorithm Repository means that TPM’s cannot natively store Ethereum private keys. Could and should change tho.
4. Workaround that I’m going to do after my first patch set is completed: software ECDSA for p256k1, i.e. signing and verification. Allows to root the keychain to an asymmetric TPM2 key.

Feels like 25-30 mins to me. Most importantly, not much knowledge required of #Ethereum, which is pretty alien topic to me :-) About to head soon to the #Tampere airport.

I’m not really even a fan of blockchains or cryptocurrency but I still think that it is good to provide safe and usable mechanisms for any legit task that user wants to use Linux for. So thus I want to enable those and free of charge, in order to keep my position regarding this topic (no affiliations). I only benefit flights to Prague from this work (pay for Airbnb myself).

#linux #kernel #crypto

This effort is spun of when I met some Ethereum Foundation ppl that I just happen to know outside of that spectrum, and they asked me to come to tell something about Linux to Ethprague (next weekend), and i needed a topic for that. I own 0 ETH and know only some rudimentary info how it works. As a follow-up for this patch set I'm planning to do p256k1 curve software implementation for crypto so that at least you can root those keys to a TPM.

Sorry for spamming I’ve spent with ASN.1 for last 9-10 days almost without sleep writing asymmetric keys code and thinking mostly of this file format and tpm protocol shenanigans… Ongoing patch set it is here https://lore.kernel.org/linux-crypto/20240528210823.28798-1-jarkko@kernel.org/.

My biggest bummer in TCG ECC support is the lack of TPM_ECC_SECP_P256_K1 curve but I’ve already started campaign to add it to the TCG Algorithm Registry. I.e. crypto wallet inside TPM curve. I sort of pushed this because I really wanted to try if I could put Ethereum keys to TPM but I guess it was good that I did not because it kept the motivation high, and sleep low ;-)

@Foxboron For encoding I actually prefer no library at all, e.g. this is first PoC actually first ECDSA signature generator existing in Linux kernel (existing ECDSA code is AFAIK just verification) although for now implemented only inside tpm2_key_ecdsa:

/* Encode the ASN.1 signature: */
#define TPM2_KEY_ECDSA_SIG_SIZE		(2 + 2 * (2 + SHA256_DIGEST_SIZE) + r_0 + s_0)
	pr_info("sig_size=%d\n", TPM2_KEY_ECDSA_SIG_SIZE);
	ptr[0] = 0x30; /* SEQUENCE */
	ptr[1] = TPM2_KEY_ECDSA_SIG_SIZE - 2;
#define TPM2_KEY_ECDSA_SIG_R_TAG	2
#define TPM2_KEY_ECDSA_SIG_R_SIZE	3
#define TPM2_KEY_ECDSA_SIG_R_BODY	4
	ptr[TPM2_KEY_ECDSA_SIG_R_TAG] = 0x02; /* INTEGER */
	ptr[TPM2_KEY_ECDSA_SIG_R_SIZE] = SHA256_DIGEST_SIZE + r_0;
	ptr[TPM2_KEY_ECDSA_SIG_R_BODY] = 0x00; /* maybe dummy write */
	memcpy(&ptr[TPM2_KEY_ECDSA_SIG_R_BODY + r_0], r, SHA256_DIGEST_SIZE);
#define TPM2_KEY_ECDSA_SIG_S_TAG	(4 + r_0 + SHA256_DIGEST_SIZE)
#define TPM2_KEY_ECDSA_SIG_S_SIZE	(5 + r_0 + SHA256_DIGEST_SIZE)
#define TPM2_KEY_ECDSA_SIG_S_BODY	(6 + r_0 + SHA256_DIGEST_SIZE)
	ptr[TPM2_KEY_ECDSA_SIG_S_TAG] = 0x02; /* INTEGER */
	ptr[TPM2_KEY_ECDSA_SIG_S_SIZE] = SHA256_DIGEST_SIZE + s_0;
	ptr[TPM2_KEY_ECDSA_SIG_S_BODY] = 0x00; /* maybe dummy write */
	memcpy(&ptr[TPM2_KEY_ECDSA_SIG_S_BODY + s_0], s, SHA256_DIGEST_SIZE);
	ret = TPM2_KEY_ECDSA_SIG_SIZE;

For encoding despite ugly it is just nice to be able to see the byte dump that gets generated at one site without having to cross-reference. I tried first asn1_encode_* functions but came into conclusion that they do more harm than good for my use because you only need to stare one location when you manually verify or debug it :-)