Personally I think that it would make a lot of sense to have this type of meta-data in DNS attributes. I.e. some means to say that this IP is a blockchain node and the type of the blockchain. Not much else but it could help a lot with low cost.

I've talked to my colleagues that one thing that strikes me in presentations given about any blockchain technology, is that they have a problem that the presentation goes straight into cryptography and smart contracts.

What you *actually* should start with is how the network discovery works. I.e. plain and simple how network nodes find each other. It's not flashy but it is like the first question for any seasoned engineer.

In order to do the secret handshakes you need to first bump into someone else to do your dance.

@cesarb @pid_eins Also even if all those procedure were taken care of (rescue password locked into PCR's), I would never use a computer, which has been physically compromised. A physical compromise is a game over as far as I'm concerned, and TPM's work best against software attacks :-) That has been the driving design goal in the standard.

@cesarb @pid_eins For my home desktop I would never lock password into the PCR's, i.e. that really should be a choice. Depends on deployment really.

@ljrk @pid_eins Thanks for all the feedback on this (from everyone who comments, all comments were useful).

I posted this mainly because could not get the gist, and was wondering do I have some blind spot here, that's all.

There's like a drum roll but no drop...

@pid_eins This was circling around social media, I read it 3~ times, and could not catch the dragon tail...

The only thing I also did catch was that "PCR 7 locking is unsafe", which is obviously dead obvious, so I guess this is noise about nothing then :-)

Multiple capture/output devices issue in the OOT driver and v4l2-loopback. It has the unfinished "SPLIT_DEVICES" compilation options, which I DO NOT fully cope with. I don't get what the heck they are aiming for TBH.

A video device can be either something like camera or something that takes input from client and displays that, e.g. similar device to ChromeCast would be a good example in this context.

I'm aligning to a solution where the initial "ADD" ioctl has:

1. flags (for setting the RW properties)
2. video_nr
3. video_fd (for server to read OR write)

And the direction is determined by flags. I did not fully understand why OOT driver aimed to do both capture and output device simultaneously, which does bother me a bit since it would be best to know the original reasoning, even if the conclusions were wrong.

Moving slowly in this area still and experimenting with options.

#linux #kernel #media #video4linux

1. The first API breaking change: https://git.kernel.org/pub/scm/linux/kernel/git/jarkko/linux-tpmdd.git/commit/?h=v4l2-loopback&id=64dd521682c305567ffa99929a09e2ba285be52e
2. The reflective test change: https://codeberg.org/jarkko/v4l2-loopback-test/commit/436818003b9865a9a4af2d872bd09acae84c178e

awesome, at least it is a pass (did not test before wrote that) :-) so a baby step, but one forward...

At least something done in the kernel side for the v4l2-loopback driver this week:

1. The first baby step towards anonymous inode based loopback device: https://git.kernel.org/pub/scm/linux/kernel/git/jarkko/linux-tpmdd.git/commit/?h=v4l2-loopback&id=90235ae07630962e6dc7c6b2b67f9e94584a6b74
2. And a reflective step in my test program: https://codeberg.org/jarkko/v4l2-loopback-test/commit/8950e975817e9d9b8012880dd9f2443d2fe13c77

The next small push is to split v4l2_loopback_fops into two: one for /dev/videoX and other for the anonymous inode returned back from the ioctl.

#linux #kernel #media

Got tired of updating clangd data manually so did a quick script to automate it :

#!/usr/bin/env bash
# Copyright (c) Jarkko Sakkinen 2025

set -e

run_build() {
  make ARCH=x86_64 O=.clangd -j$(nproc)
  scripts/clang-tools/gen_compile_commands.py -d .clangd
}

run_menuconfig() {
  if [[ ! -d .clangd ]]; then
    exit 1
  fi
  make ARCH=x86_64 O=.clangd menuconfig
  run_build
}

while getopts ":m" opt; do
  case $opt in
    m)
      run_menuconfig
      exit 0
      ;;
    *)
      echo "Usage: $0 [-m]"
      exit 1
      ;;
  esac
done

if [[ ! -d .clangd ]]; then
  make ARCH=x86_64 O=.clangd tinyconfig
fi
run_build

#linux #kernel #clangd

Reported to rust-lang/rust if anything to get some ideas how to fix this in the downstream:

https://github.com/rust-lang/rust/issues/135704

It's weird...

#rust #rustlang

@pid_eins any thoughts on this one?

https://oddlama.org/blog/bypassing-disk-encryption-with-tpm2-unlock/ #systemd #tpm #tpm2

Related to the recent #LWN article: can Sequoia already all kernel maintainer workflows or not?

https://www.linkedin.com/posts/marklemley_i-have-struggled-with-how-to-respond-to-mark-activity-7284685204676362241-7h9r

It feels suboptimal that each fedi service requires a different account.

e.g. I have a Flohmarkt instance, which is different from my Mastodon instance. If I also ran a pixelfed instance, that would be a third account.

Rather than one "me", with different linked services.

Perhaps there is a need for a fedi directory service / "main" account, which people can use for discovering of sub-accounts?

(I can see that, for some users, separation of accounts will be valuable, so I wouldn't want to remove that ability.)

C library and Rust crate recommendation of the day:

1. C: https://github.com/emoon/minifb
2. Rust: https://github.com/emoon/rust_minifb

This is pure gold!

A simple no bullshit framebuffer that dumps to X11/Wayland/macOS/iOS/Android/Web(WASM).

C library and Rust crate recommendation of the day:

1. C: https://github.com/emoon/minifb
2. Rust: https://github.com/emoon/rust_minifb

This is pure gold!

A simple no bullshit framebuffer that dumps to X11/Wayland/macOS/iOS/Android/Web(WASM).

I feel like wasting time a lot for nothing (psychologically) but at the same I think here lies the main reason why this driver has not moved really :-)

In order to modify the driver you would have to change the stack around it, which is destined not to be compatible what the upstream expects. There's no tools outside v4l2-loopback stack that you could really use for testing the camera side, when you start breaking the API.

So in order to start doing even basic changes to the driver (other than make it compile as in-tree driver), something that resembles enough stack is a mandatory requirement. Thus, this silly demo is sort of like v4l2-loopback tools emulator...