Not only #rustlang problem with Rust bindings but also an issue with e.g. #Python bindings: you cannot really use them to do any QA for upstream project, unless they are maintained by that project.

The reason being that they are not guaranteed to be in-sync with upstream changes.

The most of #autotools based open source software is sort of anti-pattern for QA/CI because the test suite is hard-bound to the source project. This is the reason why I rarely (or almost never) run TPM2 TSS test suite.

I wonder if #rustlang continues to follow this anti-pattern or is there cargo install for the test?

It is sort of thing that has been always bad for anything with disjoint host and target system but is part of “craftmanship” because things has been done that way long enough :-)

I think I will aim at building OS image per CI cycle for keyutils. This guarantees a kernel with configuration options to provide maximum coverage.

For .gitlab-ci.yml I guess it makes sense to then just limit to the branch master i.e. review is manual but red flags will rise up if the reviewer was sloppy :-)

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 🙂