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

@Foxboron Kernel has IMHO nice approach for parsing ASN.1 written a long time ago by David Howells but still legit, safe and fast:

1. scripts/asn1_compiler.c: compiles ASN.1 as bytecode with callbacks called “actions” written in C.
2. lib/asn1_decoder.c: there’s a function that takes a blob containing bytecode program for a particular ASN.1 definition and buffer containing der-file. Then the function interprets the whole thing using two arrays: machine[] for opcodes and actions[] for callbacks.

Parsers become quite strict and safe as any instance of parser does not try to parse every possible ASN.1 but fails on anything else than one single particular ASN1 format.

I recently went through ASN.1 crates for Rust with the idea of doing experimental CONFIG_ASN1_RUST flag, but none of the crates I found (looked e.g. every single one from crates.io) was not even near the quality of this elegant approach. Well-designed C can be safer than improperly designed Rust, and this good example of it.

If I did an ASN.1 parser in user space with Go, I’d use the gist of this design even on that.

The project itself could have bunch for ASN.1 files in its repository and the build process would pre-compile the parsers for each one of them. Then based on the OID, the decoder could just pick the right parser from cache indexed by the OID.

Thought to share this because I love the design and have not seen this idea implemented in user space.

I completely forgot I uploaded VistaPro 3.20 (the scenery renderer) to the Internet Archive, where you can run it from your browser. For those sudden urges of wanting to create some landscapes.

https://archive.org/details/vistapro320

Includes the MakePath tool.

Don't forget to take screenshots of your creations! Nothing can be retrieved from the disk the in-browser DOSBox keeps, as far as I know.

(Please be patient with the Archive's speed, they're dealing with persistent DDoS attacks at the moment)

@mort @gregkh s/fuck/hug/ 🌼

@harrysintonen Quite recent RNG. Added to my backlog after looking from Wikipedia the implementation: "FPGA exercise: https://en.wikipedia.org/wiki/Permuted_congruential_generator";. Perfect learning for my low FPGA skills with low-end'ish Lattice FPGA ;-) [but with open source stack, which is rare]. Thx.

Also this will purposely bound to Linux at least for now. E.g. it should be able to interact directly with kernel keyring.

So the first goal would be to make this dump into two commands:

tpm2_createprimary --hierarchy o -G ecc -c owner.txt
tpm2_evictcontrol -c owner.txt 0x81000001
openssl ecparam -name prime256v1 -genkey -noout -out private.pem
tpm2_import -C 0x81000001 -G ecc -i private.pem -u key.pub -r key.priv
tpm2_encodeobject -C 0x81000001 -u key.pub -r key.priv -o key.priv.pem
openssl asn1parse -inform pem -in key.priv.pem -noout -out key.priv.der

The.idea is to make it more like use-case oriented tool rather than one that maps the protocol as “plumbing” commands.

@colinianking One tool that I missed most is the error decoder, which can show the constant name on which I've been unsuccessful with other options ;-) Contributions are welcome but I might relicense the code base as MIT.

While developing asymmetric TPM2 keys, and reviewing TPM bus encryption earlier, I came to realize that both tpm2-tools and ibmtss feel unintuitive.

So I started to seek, if some had ever backed up my old tpm2-scripts, from which kselftest was inherited. I did not have anymore any repo for that one.

With Google I luckily found a backup from the Github profile of @colinianking, so thank you for that. Then I just copied over latest version of just tpm2.py (GPL/BSD dual-licensed file).

Probably will have some incompatibility issues with old scripts and updated main module (less than 10 updates in its total life-time tho) but I will fix them as soon as I need to test anything.

Anyway, a new and to-be-lean TPM2 hacking tool has been initiated: tpm2ctl (there’s no even file of that name yet but definitely will be at some point ;-)).

URL: https://gitlab.com/jarkkojs/tpm2ctl

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

Ever wondered why @torvalds coined the #Linux #kernel's "no regressions" rule? He just explained it again here: https://lore.kernel.org/all/CAHk-=wgtb7y-bEh7tPDvDWru7ZKQ8-KMjZ53Tsk37zsPPdwXbA@mail.gmail.com/

'"[…] I introduced that "no regressions" rule something like two decades ago, because people need to be able to update their kernel without fear of something they relied on suddenly stopping to work. […]"'

Follow the link for context and other statements that did not fit into a toot.

#LinuxKernel #regressions

@ljs @kernellogger @torvalds Yeah, it is more important how you react when by a plain mistake a regression is introduced, than not introducing them at all, i.e. transparency and brutal honesty is the key IMHO :-)

And also, for instance with this fresh bus encryption feature for TPM chips, despite getting only a single performance regression report from a private user so far, I scaled "default y" down to "default X86_64" because that is the only platform where I've been able to test it successfully even with an old Intel Celeron NUC.

I would also emphasize this as a maintainer: even if the new feature is exciting, scale it down *eagerly* before it hits a release. It is always easier scale up later on, than scale down. I tend to label "uncertainty" as a regression despite not having better knowledge rather than "wait and see". I'd label any other behavior as pure ignorance: you knew that shit might hit the fan but did absolutely nothing.

Emailed to TCG:

Forwarded message from Trusted Computing Group on Wed May 29, 2024 at 1:58 PM:
Message Body:
Some views on topic I've written:
- https://social.kernel.org/notice/AiNuw35YY9uOSrhiK0
- https://github.com/wolfSSL/wolfTPM/issues/356
Linux kernel patch set ongoing which made me realize that p256k1 is lacking from your registry:
- https://lore.kernel.org/linux-integrity/20240528210823.28798-1-jarkko@kernel.org/
This really should exist despite not being the most secure ECC given the compatibility to a number o
f open source projects and platforms (not just ETH and BTC). Please read also the above links, the w
rite ups are short and to the point. This would add by factors the importance of TPM2 ecosystem spre
ading to new applications.

--
This e-mail was sent from a contact form on Trusted Computing Group (https://trustedcomputinggroup.o
rg)

On possibility of adding TPM_ECC_SECP_P256_K1 curve to https://trustedcomputinggroup.org/wp-content/uploads/TCG-Algorithm-Registry-Revision-1.34_pub-1.pdf

Unless I overlooked something, which is entirely possible, Linux does not know how to sign even NIST-ECDSA (p256r1). That would make tpm2_key_ecdsa the first module that can do ECDSA signatures at all.

I think after TPM2 RSA/ECDSA work lands to mainline, I'll make software implementation of p256k1 ECDSA verification, and some time later, signing. That way at least TPM2 keys can root a key hierarchy for p256k1 keys to the Linux keyring, despite being just software implementation.

Stefan Berger has done during last 2-3 years a decent ecc_* API so should not be even a huge stretch.

So tpm2_key_ecdsa (if I did not overlook anything, cannot be 100% sure) might even enable ECDSA signing overall for Linux kernel for the first time.

#linux #kernel #keys #keyring

https://curl.se/libcurl/

Connecting to #Ethereum Name Service and similar crazy crypto distributed hellholes is dead easy with C: #libcurl. Also much more transparent than those crazy #Web3-frameworks :-) I don't know what they do in the machinery, so thus do not like them.