For both integration tests of my #ZMODEM crate and also for keyutils Gitlab #CI I’ve been looking for solution to implement transparent serial file transfer.

#QEMU allows trivially to convert serial port to UNIX domain socket but it is not natively supported by sz but with a little bit of socat magic it can be apparently converted quite easily again to PTY:

socat -d UNIX-CONNECT:output/images/serial.sock  PTY,raw,echo=0,link=output/images/ptyC0

This allows to drop SSH support completely from BuildRoot config, which makes it much more appealing for automated CI.

I actually ended up putting both serial and monitor as sockets along the lines of:

For using #QEMU in #CI generating ephemeral #SSH key pair is one option but after playing for a while with that option I realised that you can create named pipes:

mkfifo tty.{in,out}

And then pass -serial pipe:tty to QEMU. After this commands can be emitted to tty.in and the output can be read from tty.out.

I think this a quite good strategy when having to orchestrate headless QEMU instances without any high-level infrastructure, such as libvirt.

@peterkorsgaard Benefit of all this is sort of niche but still important: most of the testing of kernel patches in linux-integrity could be then with the upstream BuildRoot’s QEMU and UEFI targets, only changing option or few in the config and sometimes using LINUX_OVERRIDE_SRCDIR for in-development stuff.

@peterkorsgaard Or actually they could be there also when swtpm is installed as a system package (via command -v swtpm check).

@peterkorsgaard When upstreaming I’ll also probably want to update start-qemu.sh.in to use getopt for the sake of having easy to comprehend --tpm-version=<1,2> --tpm-device <tis,crb> parameters (when swtpm is enabled for host)

@peterkorsgaard thanks, will fix :-)

@peterkorsgaard Yes, eventually! I'll just let it mature a bit in here before doing that :-)

GIF-animation was generated with asciinema and agg.

I packed swtpm for the #QEMU build so it does not have to be installed to the system:

https://github.com/jarkkojs/tpmdd-buildroot-external

start-qemu.sh will automatically setup shenanigans so that swtpm will work as TPM emulation host for QEMU.

After build there’s three options:

1. TPM2 TIS/FIFO: output/build/images/start-qemu.sh
2. TPM2 TIS/CRB: output/build/images/start-qemu.sh --tpm-crb
3. TPM1 TIS/FIFO: output/build/images/start-qemu.sh --tpm1

Right, and neither QEMU needs to be installed to the host. I’m trying to sort of construct this in a way that it would become as CI friendly as possible so that this could be in addition used as a CI workload for keyutils.

#BuildRoot #linux #kernel #tpm

After some experimentation it is best the define boards in this context as fairly self-contained packages to the specific test devices at hand and not have anything shared e.g. by CPU architecture even at the cost of some redundancy:

$ tree
.
├── Config.in
├── LICENSE
├── board
│   └── tpmdd_qemu_x86_64
│       ├── linux.config
│       ├── post-build.sh
│       ├── post-image.sh
│       └── start-qemu.sh.in
├── configs
│   └── tpmdd_qemu_x86_64_defconfig
├── external.desc
└── external.mk

4 directories, 9 files

E.g. similarly I’ll add tpmdd_raspberrypi3b target and so forth. For instance, I would not share post-image.sh and similar scripts between boards even if they were 1:1. It kills robustness.

The orchestrator itself has a flat repository:

$ tree
.
├── LICENSE
├── Makefile
└── README.md

I licensed external with GPL2 for the sake of upstream compatibility and orchestrator with MIT. This is overally pretty usable structure to use Buildroot.

My new (WiP) orchestrator for building test image for testing my #kernel tree is fully implemented with GNU make:

# SPDX-License-Identifier: MIT

ROOT			:= $(dir $(abspath $(firstword $(MAKEFILE_LIST))))
BUILDROOT_VERSION	:= 2023.11
OUTPUT			:= $(ROOT)output
BUILDROOT_URL		:= https://buildroot.org/downloads/buildroot-$(BUILDROOT_VERSION).tar.gz
EXTERNAL_URL		:= https://github.com/jarkkojs/tpmdd-buildroot-external/tarball/main

define make-buildroot
	make -C "$(OUTPUT)/buildroot" BR2_EXTERNAL="$(OUTPUT)/external" O="$(OUTPUT)/build" $(1)
endef

define download-package
	mkdir -p $(2)
	curl -sL "$(1)" | tar -zxv -C "$(2)" --strip-components=1
endef

all: buildroot

.PHONY: buildroot
buildroot: $(OUTPUT)/download-stamp
	$(call make-buildroot,tpmdd_qemu_x86_64_defconfig)
	$(call make-buildroot,all)

.PHONY: buildroot-menuconfig
buildroot-menuconfig: $(OUTPUT)/download-stamp
	$(call make-buildroot,tpmdd_qemu_x86_64_defconfig)
	$(call make-buildroot,menuconfig)
	$(call make-buildroot,savedefconfig)

.PHONY: linux-menuconfig
linux-menuconfig: $(OUTPUT)/download-stamp
	$(call make-buildroot,tpmdd_qemu_x86_64_defconfig)
	$(call make-buildroot,linux-menuconfig)
	$(call make-buildroot,linux-savedefconfig)

$(OUTPUT)/download-stamp: 
	$(call download-package,"$(BUILDROOT_URL)","$(OUTPUT)/buildroot")
	$(call download-package,"$(EXTERNAL_URL)","$(OUTPUT)/external")
	touch $@

.PHONY: clean
clean:
	rm -rf "$(OUTPUT)"

It is pretty robust structure because I can e.g. easily add packages (like maybe host swtpm) in a robust manner to buildroot.

#buildroot #linux

To test latest linux-tpmdd changes:

git clone https://github.com/jarkkojs/test-tpmdd
cd test-tpmdd
make

Then:

1. TPM2 TIS/FIFO: output/images/start-qemu.sh --swtpm
2. TPM2 TIS/CRB: output/images/start-qemu.sh --swtpm --tpm-crb
3. TPM1 TIS/FIFO: output/images/start-qemu.sh --swtpm --tpm1

Tools for testing (more in future):

• keyutils for testing keyring and trusted keys
• /usr/lib/kselftests/run_selftests.sh

Requires swtpm to be installed (but not QEMU, it will build one).

#linux #kernel #buildroot

took sort of more productized approach by using `BR2_EXTERNAL` so that I don't have to touch #BuildRoot's Git history: https://github.com/jarkkojs/test-tpmdd

I'll focus on x86_64 first and then work on adding Raspberry Pi 3B+ support back.

https://github.com/jarkkojs/test-tpmdd

#linux #kernel

@monsieuricon lot to digest, i did read it couple of times yesterday but really have to digest before responding. one constraint which should probably be set that it should be adaptable somehow to gitlab later on (not meaning that it must adapt right now but make sure that it is doable).

Work Hard. Play Hard.

@boxdot hey thanks! it does look promising 🙂

Zuckerberg heading into 2024

What is a good strategy when having a C project and you'd want to start converting subportions of it to Rust? The project in question uses just plain makefiles and glibc.

Looking for some idiomatic patterns if such have been invented and documented.

#rustlang #posix

@vbabka do no get threat scenario but this is luckily quite functional extension for TB to write emails: https://github.com/Frederick888/external-editor-revived. There's external program in addition to extension but it is easy to setup. If you launch it without parameters it will tell you where to place a simple js file, of which contents it also outputs and after that TB takes care of launching it when it needs it

With email the threat scenario is mostly emails themselves and I cannot 100% guarantee that I do not fall on phishing unless I use text based email client :-)