@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 :-)

And you can easily use it for generating extra wave cycles for saw too...

meaning that the day has come that i can finally fully capture VB-1 :-) people still use VB-1 a lot. it is sort of 303 of vst's. crappiest bass emulation ever but has sort of its own color. one of the first vsts ever released.

"easter eggs" in #Xfer #Serum and #SerumFX

Linus might be willing to drop support for i486-class machines[1] from the #Linux #kernel.

No, nobody asked for that directly; he brought that up in a discussion himself: https://lore.kernel.org/all/CAHk-%3DwhESMW2v0cd0Ye%2BAnV0Hp9j%2BMm4BO2xJo93eQcC1xghUA@mail.gmail.com/ #LinuxKernel

[1] and a couple of processors which _claimed_ to be Pentium class, but weren't

@mkelly Yes, exactly. It sort of makes the hardware fit for the exact purpose you are using it :-)

@vbabka it is corporate 365 with all sorts of things blocked that usually work. No app passwords, no EWS, apparently they check client ID/password for TB because e.g. Evolution does not work.