I wonder why vfat in kconfig does not select these options:

• CONFIG_NLS_CODEPAGE_437
• CONFIG_NLS_ISO8859_1

Noticed this while putting together #systemd image. You really cannot use FAT meaningfully without 437, so there should be IMHO either depends or select relation between these and FAT kconfig options.

In my opinion selecting VFAT in 2024 from kconfig should lead to selecting all the options that are required for filenames at minimum because it has exactly two use cases:

1. USB sticks
2. ESP

In both cases proper interpretation of filenames is required.

PS. I also wonder why systemd does not list them as its required CONFIG_*. They are not obvious kconfig options in the context of kernel QA ;-) I always begin with tinyconfig and add up from there when doing this. Using ESP is required by practical means with systemd-boot so all three options should exist in this file: https://github.com/systemd/systemd/blob/main/README. I used it as a reference and failed.

#linux #kernel #vfat #codepage #437

Ramping up #systemd #kernel #QA: DONE!

URL: https://gitlab.com/jarkkojs/linux-tpmdd-test

Contents:

CMakeLists.txt
Config.in
LICENSE
README.md
board/x86_64/buildroot.conf
board/x86_64/genimage.cfg
board/x86_64/kselftest-tpm2.exp.in
board/x86_64/linux.config
board/x86_64/post-build.sh
board/x86_64/post-image.sh
board/x86_64/run-qemu.sh.in
board/x86_64/run-tests.sh.in
board/x86_64/ssh_config.in
buildroot-2024.02.3.patch
configs/x86_64_defconfig
external.desc
external.mk

I’ve been editing the history while ramping up this starting point but I will stop this chaotic workflow now and commit to this baseline :-) So no worries if sending pull requests…

This is also CI capable environment assuming that runner has:

• QEMU
• swtpm

The GIF-animation shows the proof that it actually also works.

Yup, I think it is most sensible to make asymmetric TPM2 key signer only, and import public key to software asymmetric key.

It's not purely just doing TPM2_Sign but also per signature type (RSAPSS, ECDSA etc.) it needs signature specific encoder to ASN.1 format.

Still sufficient to have only a single tpm2_signing_key type of module.

This happens to me at least every second or third day:

# poweroff

And then my computer shuts down :-) #qemu

Before even considering any changes to the #kernel #PGP #maintainer guide I wonder what is the use and purpose of:

- gpg-agent-browser.socket
- gpg-agent-extra.socket

I keep them disabled because I need only gpg-agent.socket and gpg-agent-ssh.socket but for completeness sake would be nice to know what they are.

What do in my custom #BuildRoot and #systemd based image to this error:

[FAILED] Failed to mount EFI System Partition Automount.                                                                     
See 'systemctl status efi.mount' for details.                 
[  OK  ] Finished Update Boot Loader Random Seed.             
tpm_tis MSFT0101:00: 2.0 TPM (device-id 0x1, rev-id 1)        
random: crng init done                                        
[  OK  ] Started Network Name Resolution.                                                                                    
[  OK  ] Reached target Host and Network Name Lookups.                                                                       
         Mounting EFI System Partition Automount...           
         Starting Virtual Console Setup...                    
[FAILED] Failed to mount EFI System Partition Automount.                                                                     
See 'systemctl status efi.mount' for details.                 
[FAILED] Failed to start Automatic Boot Loader Update.        
See 'systemctl status systemd-boot-update.service' for details.

I have no idea what those error messages mean.

The source is here: https://gitlab.com/jarkkojs/linux-tpmdd-test

And here’s the output for the “details”:

# systemctl status systemd-boot-update.service
× systemd-boot-update.service - Automatic Boot Loader Update
     Loaded: loaded (/usr/lib/systemd/system/systemd-boot-update.service; enabled; preset: enabled)
     Active: failed (Result: exit-code) since Wed 2024-06-12 01:50:17 UTC; 2h 58min left
       Docs: man:bootctl(1)
    Process: 87 ExecStart=bootctl --no-variables --graceful update (code=exited, status=1/FAILURE)
   Main PID: 87 (code=exited, status=1/FAILURE)
        CPU: 28ms

Jun 12 01:50:15 tpmdd systemd[1]: Starting Automatic Boot Loader Update...
Jun 12 01:50:17 tpmdd bootctl[87]: Failed to open parent directory of "/efi": No such device
Jun 12 01:50:17 tpmdd systemd[1]: systemd-boot-update.service: Main process exited, code=exited, status=1/FAILURE
Jun 12 01:50:17 tpmdd systemd[1]: systemd-boot-update.service: Failed with result 'exit-code'.
Jun 12 01:50:17 tpmdd systemd[1]: Failed to start Automatic Boot Loader Update.

#linux #kernel #testing

OK, cool, #systemd is booting now with systemd-#boot. The problem was simply that I did not package all the required files with #genimage :-)

Even tho this image built only for #kernel test and could in theory run just bzImage as #ELF-executable, systemd-boot makes sense given the ability to modify the kernel command-line without compiling the kernel.

So I can now conclude that I've migrated from #busybox to systemd in my kernel testing workflow :-)

#linux

I'm re-formalizing my question because I could wrong too

Using any formation of #Signal App, is it possible to get #SGX #attestation of contact discovery back to the client and view the certificate, or how does it benefit the end user?

Or is from client possible to get this attestation using the raw protocol that the app uses?

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.