Trying to make a new version of my “TPM2 signers” patch set and stumbling into a weird problem.

Here’s the script I’m looking at:

#!/usr/bin/env bash

set -e

PRIMARY=0x81000001

function egress {
  keyctl clear @u
  tpm2_evictcontrol -C o -c $PRIMARY 2> /dev/null
  tpm2_getcap handles-transient
  tpm2_getcap handles-persistent
}
trap egress EXIT

openssl ecparam -name prime256v1 -genkey -noout -out ecc.pem
openssl pkcs8 -topk8 -inform PEM -outform DER -nocrypt -in ecc.pem -out ecc_pkcs8.der

tpm2_createprimary --hierarchy o -G ecc -c owner.txt
tpm2_evictcontrol -c owner.txt $PRIMARY

# EC parameters to TPM2 blob:
tpm2_import -C $PRIMARY -G ecc -i ecc.pem -u tpm2.pub -r tpm2.priv

# TPM2 blob to ASN.1:
tpm2_encodeobject -C $PRIMARY -u tpm2.pub -r tpm2.priv -o tpm2.pem
openssl asn1parse -inform pem -in tpm2.pem -noout -out tpm2.der

# Populate asymmetric keys:
tpm2_ecc_key=`keyctl padd asymmetric "tpm_ecc" @u < tpm2.der`
kernel_ecc_key=`keyctl padd asymmetric "kernel_ecc" @u < ecc_pkcs8.der`

echo "SECRET" > doc.txt

echo TPM2 ECC SIGN
keyctl pkey_sign $tpm2_ecc_key 0 doc.txt hash=sha256 > doc.txt.sig

echo TPM2 VERIFY
keyctl pkey_verify $kernel_ecc_key 0 doc.txt doc.txt.sig

The error message generated is:

keyctl_pkey_verify: Invalid argument

If I verify with the TPM2 ECC key /it will pass, in other words replacing the list statement with:

keyctl pkey_verify $tpm2_ecc_key 0 doc.txt doc.txt.sig hash=sha256

In the final version I’m going to remove signature verification from TPM2 ECC key as that is kind of the point here: sign certificate with a private key protected by TPM and allow any party verify the signature with the known public key.

#linux #kernel #tpm

@josh @osi For me this looked initially like as some sort of magic spell that a corp can say and then they just continue to do whatever shit they were doing before because they've just been "we're not doing evil stuff" stamped or something.

@josh @osi I had the same thoughts week ago but I tend to be a bit spiky from time to time so I thought maybe I was a bit too judgemental (which happens too often). Good to hear others reflect my first views on this. Thanks for writing this.

https://social.kernel.org/notice/AnPuVswNBKAitj9wxc

@aks Making difference between "rotten looking" and "rotten" is important especially since messy but functional is always better than clean and dysfunctional. It is a psychological more so than technical challenge to remember this ;-) https://www.joelonsoftware.com/2000/04/06/things-you-should-never-do-part-i/

@aks By following this, the rotten looking parts will get treatment within shorter timeline some commentary. This way at least not dumpsters of legacy will form...

Sometimes bad looking solution can have non-intuitive but still legit reasoning - all rotten looking is not actually rotten ;-)

These are at least my empirical learnings over the years working with open source...

Both fixes landed :-)

@aks It is sometimes hard to identify at the time. I'd suggest more like "comment on the first scratch" approach. Every time there's any issue that should lead either to:

1. A new inline comment
2. A new test case

If you start to seek appropriate places while implementing a feature, that can lead to over-saturation of comments, which dissolves the important ones.

PR for 6.12-rc7 with a fix for recently reported bug:

1. https://lore.kernel.org/linux-integrity/D5CYH0IJXX72.35A25M1YICZRP@kernel.org/T/#u
2. https://bugzilla.kernel.org/show_bug.cgi?id=219383

This bug for early weeks of the current release cycle has already landed: https://bugzilla.kernel.org/show_bug.cgi?id=219229

Right now that I don't do kernel as my main job I prioritize users instead kernel developers when picking fixes for during the cycle PR's :-) Other fixes can wait until 6.13 PR.

#linux #kernel

@ljs reminds me of wonderful adventures of nils holgerson

@ljs background picture material love it

@mrmasterkeyboard This configuration allows me to even build new version of OpenSBI for every build, i.e. I get end-to-end open source stack built by BuildRoot, and has one cable less (no separate power cable) than Raspberry Pi.

The next step I'm planning to improve this is adding JTAG probe into it :-) I have one waiting for this already.

@mrmasterkeyboard

I don't know what you mean by "green board" and "black board" but this is:

1. VisionQuest 2 RISC-V board
2. A shield providing RS-232 through USB ordered from AliExpress
3. LetsTrust TPM SPI module (Infineon SLB 9672)

I do most of kernel testing in QEMU ATM but this is my bare metal choice because single USB cable gives both power and serial link and board has jumpers to configure it to SDIO mode (i.e. all stages read from provided SD card). RISC-V is a bit irrelevant here but gives confidence that changes work in multiple platforms and not just on x86. And also slowness is a feature for catching performance regressions.

The “convenience of LSP” with kernel:

make ARCH=x86_64 O=../linux-tpmdd-clangd x86_64_defconfig
make O=../linux-tpmdd-clangd/ CC="ccache gcc" -j`nproc`
scripts/clang-tools/gen_compile_commands.py -d ../linux-tpmdd-clangd

This is least distracting way I’ve found to use it (I use it only with VSCodium when just browsing around):

1. Uses host architecture (target architecture can be “whatever”).
2. Uses defconfig that works well for this task.
3. Does not disturb other uses of the Git tree.

E.g. I use LINUX_OVERRIDE_SRCDIR a lot with BuildRoot and usually clean kernel directory in such cases causes least troubles…

my main hardware test platform for Linux kernel. spot the tpm chip 🙂 #linux #kernel

"I can replace you lazy fucks with spicy autocomplete."

"More than a quarter of all new code at Google is generated by AI, then reviewed and accepted by engineers," CEO Sundar Pichai said on the company's third quarter 2024 earnings call. If you work...
https://jwz.org/b/ykb8

Midnight Commander is still the best file manager thanks to '--printwd', which writes the last seen working directory to a file. This amazes me because it is a feature that requires almost nothing to implement.

Second trial:

https://lore.kernel.org/linux-integrity/20241102152226.2593598-1-jarkko@kernel.org/T/#t

It's guaranteed race-free (as patch set version does not take ops_sem into account) and for anything security usually it is just only good practice to keep functionality irreversible (one-shot) on success as repetition is bad for security ;-)

... and a test program in Rust: https://codeberg.org/jarkko/tpm-set-locality-test/src/branch/main/src/main.rs

For Trenchboot: https://lore.kernel.org/linux-integrity/20241102013716.1036396-1-jarkko@kernel.org/

#linux #kernel

@paulthenerd My guess from this that audio parts of e.g. Thinkpad hae TCO of few euros or something :-) I.e. complete and total garbage. Better if the audio chipset did not exist at all. In fact, I often disable the laptop audio chipset from BIOS as the first thing. PC speaker at least does its job