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.

Dropped this question also to #wolfSSL: https://github.com/wolfSSL/wolfTPM/issues/356

#Microsoft has invested considerable amount of money on #Ethereum but still nobody has put forward p256k1 to the TCG Algorithm Registry. IMHO, would be somewhat dead obvious thing to do...

https://trustedcomputinggroup.org/resource/tcg-algorithm-registry/

#TPM #blockchain

I wonder if TCG is ever going to add p256k1 to their algorithm repository...

Asymmetric #TPM2 #keys v7:

https://lore.kernel.org/linux-crypto/20240528210823.28798-1-jarkko@kernel.org/T/#mb07f85a8c3f4af388cbc08438e71ac8aea447d85

This is the first version with fully working #ECDSA signing and signature verification with the public key.

Implementation notes:

1. Accepts only sha256 at this point. Can be easily extended later. It is best overall choice for the first version.
2. Does not accept any authentication policy yet. Can be extended later by adding a new parameter to match_table_t param_keys in security/keys/keyctl_pkey.c. E.g. "policy=%s".

I’m pretty happy with this, given that I did it fully during 1.5 week period on my free time and unpaid ;-)

#Linux #kernel #TPM

@GossiTheDog I'd generally prefer either Firefox or Chrome, or unbranded versions of them (like Debian's Iceweasel), even if there is zero controversies because obviously it is nearest the upstream where e.g. security fixes land first.

Linux 6.10-rc1 got released yesterday. With brand new `mseal()` system call.

So my automation kicked in, posted pull request, I merged, page with system calls table got rebuilt:

https://gpages.juszkiewicz.com.pl/syscalls-table/syscalls.html

@tshepang Ultimately I cannot say anything definitive as it is up to arch subsystem tree maintainers, but I would be less surprised to win in lottery, than see an arch subsystem tree that would require two cross-compilation toolchains to make a build. From that I can pretty much deduce the original claim that feature parity is mandatory for linux-rust to have any long-standing significance in linux kernel.

v6 of #TPM2 #asymmetric #keys patch set: https://lkml.org/lkml/2024/5/28/150

The new version includes also sub-type for ECDSA signing and verification.

#linux #kernel

@tshepang Not something that pro-actively waiting for but before that happens Rust is by.practical means blocked from defconfig's. It is then up to those who work on these compilers to find a way to make it happen (such as ISO standard).

@tshepang Rust is already enabled in Linux but it has insignificant chance to reach any arch's defconfig before feature parity with gccrs. What is an "ok thing"?

@tshepang not really understanding the context where this would happen, I'm not waiting for anything at all :-)

@tshepang Because Linux supports GCC 🤷 And for anything compiled by default, i.e. in any defconfig, requiring two toolchains for a build is obnoxious and neither very portable. E.g. for specific cross-compilation target you might have only one toolchain.