#apache #tvm is somewhat involved to install #macOS laptop. At least compared to pipx install apache-tvm in my #Linux desktop.

I followed these randomly found instructions but rolled it backed immediately because I don’t want to re-spend my time on this.

Also makes me wonder how big mess compiler toolchains are in macOS really:

1. I have Xcode command-line tools installed, which I expect to readily include llvm in some form.
2. Instructions imply that I also need to install llvm, which logically makes no sense to me.
3. Instructions also imply that I need to have GCC.

Might be just that the instructions are the broken portion but feels somewhat primitive and unorganized…I’m glad I develop iOS or Mac applications because then I would actually would have to use this as a real development machine I guess :-)

PS. The official instructions for macOS do not work in macOS at all :-)

When I have had to use Windows I've WSL2 totally inconvenient environment to work in with a number of things breaking up badly. A regular VM works much better and shell access goes by SSH.

That said I think as a technology it is a great piece still. I'd see for it more use if there was way to make Windows applications that would embed Linux kernel as a run-time.

It could e.g. be used to deliver accurate software versions of hardware consumer products, which tend to run Linux quite often...

Personally, I think that these new bc replacements make me feel more like Cobol vibes with "1 kilometer - 1 meter" type of expression support than modern vibes...

Commercial Linux distribution vendors could bring a lot of confidential computing benefits by providing rate-limited attestation service (i.e. accountless like AMD SEV-SNP CA works) I.e. CA would provide cryptographic proof of the core software stack.

With TPM2 backed hard drive encryption and HMAC encrypted chip communication you get a piece of confidential computing promise, i.e. the software adversary part and you can maintain that promise with pure software bug fixes, which obviously adds in to the value.

The main threat scenario of confidential computing is an adversary with a physical access to the hardware but it is also debatable scenario, and as we all know, there is a lot of data to backup the "debatable" part.

TCG, being a consortium and not a private company, states its specifications that TPM provides resistance against physical attacks. I think this is how Intel, AMD, ARM and other commercial CPU vendors should also describe their corresponding white papers, and make any improvements on top of clear and obvious to the customer.

PS. "confidential computing" is bad terminology but unfortunately it is also defacto terminology of the industry by now. It is actually "trusted computing" because the goal is try to address both confidentiality and integrity problems.

#linux #kernel #tpm #intel #amd #arm #sev #snp #sgx

Otin kuukaudeksi Ruutu plussan ja tyttöystävän kanssa käyty läpi hieman suomirealitya:

1. Lejonan luola. Hyvä ohjelma, ja ulkomainen vastine on lempiohjelmia. On tosin moraalisesti kyseenalaista, että yksi leijonista on istuva kansanedustaja Toiset pistävät omaisuutensa pantiksi kampanjoinnin takia, joten risuja tuotantoyhtiölle.
2. Rikkaat ja rutiköyhät. En sano tätä edes vitsillä, kun totean, että on monesti vaikea arvioida, kumpi jakson perheistä on rikas, ja kumpi rutiköyhä. Tämä siksi, koska en tiedä ihmisten henkilökohtaista tasetta. Kaikkea hienoa saa velkarahalla.

#suomi #reality #tv

#Linux #kernel 6.7-rc7 is out: https://lore.kernel.org/lkml/CAHk-%3DwjDbR1oNZtqTNE4n8MHbzi028JFKSCvyW88hw%2B0GO%3DP%2BA@mail.gmail.com/

"'"[…] since tomorrow is Xmas Eve,[…] I'm doing rc7 on a Saturday instead.

[…] we *could* release a final 6.7 next weekend as per the usual schedule, I'm not going to do that. It's the holidays,[…]

So next weekend is going to be rc8, and I expect that it will be small as nobody should be around.

And then we might get back to a more normal schedule the week after. Maybe.

Please do give it a whirl if you have the time and the energy[…]"'"

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.

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.

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

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

Work Hard. Play Hard.

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

"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