Actually not yet too successful booting my #BuildRoot image with systemd-boot. With grub-efi I got to the login.

EDIT: I think I got it and it is pretty obvious. I’m still deploying GRUB style configs when I construct the disk image with genimage, so I just fix them up as systemd boot style configs (found a reference for that).

So I just follow along [1] and cross my fingers ;-) I think it is good exercise to build from scratch a systemd image from boot to user space in all cases.

[1] https://www.freedesktop.org/wiki/Software/systemd/systemd-boot/

The summary of #systemd #spam of today:

1. I got it fully working for my #BuildRoot image build.
2. It boots with no errors.
3. Compilation time is still not much different than with #Busybox.
4. Uses now systemd-boot instead of GRUB (thanks @vathpela for comments).
5. Uses systemd version 254. Plan is to get into phase.
6. For BuildRoot, uses the master branch of: https://gitlab.com/jarkkojs/linux-tpmdd-test

I “systemd” re-initiated the history of my test repository: https://gitlab.com/jarkkojs/linux-tpmdd-test. From now on I commit on keeping a proper versions on this :-) It had no forks so far so I’m the only person who had consequences on that action.

What is the advantage of systemd-boot over GRUB2? #systemd #grub #grub2

My #systemd feature awareness is always about two years old because you don’t become aware of its features by doing #kernel development :-)

For instance, I had no idea that systemd already natively supported #TPM2 before month or two ago someone told me about systemd-cryptenroll. I had seen the utility tho in some article but had a blind spot for the prefix.

Now that I’ve seen systemd’s TPM2 implementation in source level I can only say that it is somewhat bloated but I guess it is working fine :-) It is bloated because it would have been better idea just directly use the device. So not a great implementation, but at least a working one. That said, it is not a major glitch but IMHO could be rewritten at some point, with the motivation of decreasing dependencies and compilation times.

In order to address the 1-2 year turn-over issue, I’ll try to get my #BuildRoot build to generate a fully working #systemd environment.

#linux

I was able to create #systemd image with #BuildRoot.

However, it boots into emergency mode. Any tips or ideas?

My end product is 2GB img file that can be booted either with real hardware or in QEMU (it has #UEFI layout).

Shortest cheat sheet possible for xxd:

xxd -r -p | xxd -p -c 0

My lessons learned from #ethprague was these are the key algorithms:

1. P256-K1 also known as the #bitcoin curve.
2. Keccak-256, as it was before it became SHA-3. AFAIK, they have just some padding incompatibility. This is the hash used in #ethereum.

I don’t see really any problem make them a bit more “stack compatible”. So maybe something to look at after I get my TPM2 public key patch set into the mainline.

So like when running bunch of servers, how to seal your keys properly, pretty basic stuff.

When thinking about #AI #threat in general, like in a #dystopian type of situation, I'd be more concerned on whether AI can inherit in #legal terms large amounts of cash or other #fortune.

I mean... it is simple really. The current ones just turn ******g off. But, if just by pure accident the tables were turned. That is undefined society model that probably does not have even a name yet

I'm always looking for an adventure, but not the AI slavery dystopian one... Be forewarned, I mean this have at least theoretical chances of actually realizing in a form or another. More like due than potential risk IMHO.

I did not know about ~/.config/nvim/after/plugin before reading this: https://fedoramagazine.org/configuring-neovim-on-fedora-as-an-ide-and-using-lazyvim/

#teardown and #bootstrap gpg-agent, pcscd to have a working configuration:

#!/usr/bin/env sh
# Copyright (c) Jarkko Sakkinen 2024
# Bootstrap gpg-agent and pcscd for Yubikey use.

GPG_AGENT_SOCKETS=(gpg-agent-ssh.socket
                   gpg-agent-browser.socket
                   gpg-agent-extra.socket
                   gpg-agent-ssh.socket
		   gpg-agent.socket)
systemctl --user disable --now "${GPG_AGENT_SOCKETS[@]}"
gpgconf --kill gpg-agent
sudo systemctl disable --now pcscd.socket

systemctl --user enable --now gpg-agent.socket gpg-agent-ssh.socket
sudo systemctl enable --now pcscd.socket

#yubikey

Why Curve25519 uses EdDSA for signing, and SECP-P256-R1 and SECP-P256-K1 use ECDSA?

It’s the scale. Curve25519 field has the size that fits within 255 bits, and two previous have the size that fits within 256 bits.

So from that follows:

• a new signature formalization is needed to reach similar or better results.
• given the smaller size it can only reach this goal by integrating tightly to the choices of the finite field parameters.

There is formal backing for this but pure common sense it is exactly like “if loose some, you must gain some” ;-)

#cryptography #note

I realized that I have something profound broken in my asymmetric TPM2 key series: TPM2 specific keys should only sign, not verify.

struct public_key, which is the central structure used for built-in, vendor and machine owner keys, should be able to verify the signature, even when the TPM chip is removed.

As a consequence, I will delete all the verification code from the key type(s) and set the supported_ops a KEYCTL_SUPPORTS_SIGN, instead of previous KEYCTL_SUPPORTS_SIGN | KEYCTL_SUPPORTS_VERIFY.

I’ll also rework tests to have two asymmetric keys: one for signing in the chip and other outside holding only the public key. That should also better verify that the feature is working correctly.

Would be nice if #systemd would release yearly #showcase image and ISO. Twice a year would be even better but a yearly "the state of systemd" would already do miracles!

In my opinion, a working design for kernel developers for this would be an image that would have the some recent release number, and easy way to build and deploy a test kernel.

Love the name of the #systemd's python-bindings: "pystemd"

Right. I should take my TPM2 signing code and merge it to struct public_key, use only TPM2_Sign and ditch TPM2_RSA_Decrypt.

Just hit me out of the void. Then e.g. builtin/secondary/machine keyrings, x.509 certiificates etc. is also in the finish line once this feature lands :-)

Three week clocked to the development so far so I think this is going in good phase.

I’ll start a new series (because it is not the exact same feature as before).

#linux #kernel #tpm

Condolences.

Mike Karels of Berkeley Unix/BSDi died of a heart attack on his way home from BSDCon.

Karels was responsible for implementing TCP/IP on BSD, which was later ported to Linux. Since you're reading this, you are benefitting directly from his work.

RIP, Mike. We won't forget you.

https://freebsdfoundation.org/mike_karels/

Great, my patches adding host compilation for #libstpm and #swtpm was picked by the #BuildRoot upstream finally 🎂

I really like #mmv https://github.com/rrthomas/mmv/. Archaic but does not get in the way..

Like for instance:

❯  mmv -n '*.patch' '#l1.patch'
0001-basic-add-PIDFS-magic-31709.patch -> 0001-basic-add-pidfs-magic-31709.patch

Handy :-)

#mv #cp #ln #rm

Trying to deploy #systemd to BuildRoot build:

Filesystem found in kernel header but not in filesystems-gperf.gperf: BCACHEFS_SUPER_MAGIC                                                    
Filesystem found in kernel header but not in filesystems-gperf.gperf: PID_FS_MAGIC                                                            

I think I might know how to fix these tho so should not be an issue.

I had QEMU style build. I’m repeal and replacing that with a build that builds 2GB disk image ESP/UEFI compatible. That can then supplied to qemu/libvirt or burned to stick and booted with hardware.

#linux #kernel #testing

Don't get too excited: Intel TXT will be also available in #x86s ;-)

Unfortunately this is not documented yet in Intel SDM , which misguided a bit when I was reviewing Trenchboot.

Finally I found [1], which has a "3.15 SMX Changes" section and asociated pseudocode Hopefully soon also in the SDM.

So long live measured DRTM launch ;-) The future is now.

[1]
https://lore.kernel.org/linux-integrity/D1SPFVXS6FOG.IQQB3INFYEF2@kernel.org/
[2]
"X86S EXTERNAL ARCHITECTURAL SPECIFICATION"
https://cdrdv2.intel.com/v1/dl/getContent/776648

#linux #kernel #x86