Also this helped: https://frostyx.cz/posts/lsp-for-vim-boomers

;-)

After trying different approaches of using clangd with kernel my end game is to put O=./clangd for the “clangd build”, which is a host (as target) build with bunch of stuff that you want enable. This makes sense because kernel’s .gitignore has by default .*.

I also learned that for the “real Vim” (not “Gen Z vim”) there is actually quite decent set of plugins to make use of it. Here’s my vim-plug list:

  Plug 'mattn/vim-lsp-settings'
  Plug 'prabirshrestha/asyncomplete-lsp.vim'
  Plug 'prabirshrestha/asyncomplete.vim'
  Plug 'prabirshrestha/vim-lsp'

This is how I would ramp up clangd session while hacking Linux:

make ARCH=x86_64 O=./.clangd x86_64_defconfig
make ARCH=x86_64 O=./.clangd menuconfig
make ARCH=x86_64 O=./.clangd -j`nproc`
scripts/clang-tools/gen_compile_commands.py -d ./.clangd

@cmccullough It's from the guy who gave us WireGuard so it is first class bash quality code ;-)

I use it for like "root stuff", e.g. my password to 1Password. It's good to have something like that for small collection of passwords, pin-codes etc. And once you master OpenPGP with Yubikey, it's breeze to use and super secure. I always carry my subkeys in a yubikey and have a backup one at home.

@cmccullough the best of the best was not in the list: https://www.passwordstore.org/ ;-) TBH I use it in combination with 1Password, which I have no too many complains (the password obviously is in my pass store).

OpenWRT is great. I run it in my Turris Omnia, which is a great Czech made router that I love so dearly. I also love BuildRoot used to build OpenWRT images, which is IMHO the best embedded build system in the world. The whole no bullshit ecosystem resonates a lot to me really.

Thus, OpenWRT designing their own reference router called OpenWRT One is great news, and have to link the associated LWN article just to promote it:

https://lwn.net/Articles/994961/

#openwrt #buildroot #lwn

https://counterhate.com/research/musk-political-posts-x/

@itaru The single best decision in my life was to delete my Facebook account about 6 months ago (not deactivate, delete). I can only imagine how many moments of anxiety this has prevented so far :-)

The only remaining social media accounts I have is Mastodon and Bluesky.

Found a cool fabric brand while cleaning up some old boxes full of all kinds of shit. Have to learn how to sew and attach it to something. #acid #303

Trying to make a new version of my “TPM2 signers” patch set and stumbling into a weird problem.

Here’s the script I’m looking at:

#!/usr/bin/env bash

set -e

PRIMARY=0x81000001

function egress {
  keyctl clear @u
  tpm2_evictcontrol -C o -c $PRIMARY 2> /dev/null
  tpm2_getcap handles-transient
  tpm2_getcap handles-persistent
}
trap egress EXIT

openssl ecparam -name prime256v1 -genkey -noout -out ecc.pem
openssl pkcs8 -topk8 -inform PEM -outform DER -nocrypt -in ecc.pem -out ecc_pkcs8.der

tpm2_createprimary --hierarchy o -G ecc -c owner.txt
tpm2_evictcontrol -c owner.txt $PRIMARY

# EC parameters to TPM2 blob:
tpm2_import -C $PRIMARY -G ecc -i ecc.pem -u tpm2.pub -r tpm2.priv

# TPM2 blob to ASN.1:
tpm2_encodeobject -C $PRIMARY -u tpm2.pub -r tpm2.priv -o tpm2.pem
openssl asn1parse -inform pem -in tpm2.pem -noout -out tpm2.der

# Populate asymmetric keys:
tpm2_ecc_key=`keyctl padd asymmetric "tpm_ecc" @u < tpm2.der`
kernel_ecc_key=`keyctl padd asymmetric "kernel_ecc" @u < ecc_pkcs8.der`

echo "SECRET" > doc.txt

echo TPM2 ECC SIGN
keyctl pkey_sign $tpm2_ecc_key 0 doc.txt hash=sha256 > doc.txt.sig

echo TPM2 VERIFY
keyctl pkey_verify $kernel_ecc_key 0 doc.txt doc.txt.sig

The error message generated is:

keyctl_pkey_verify: Invalid argument

If I verify with the TPM2 ECC key /it will pass, in other words replacing the list statement with:

keyctl pkey_verify $tpm2_ecc_key 0 doc.txt doc.txt.sig hash=sha256

In the final version I’m going to remove signature verification from TPM2 ECC key as that is kind of the point here: sign certificate with a private key protected by TPM and allow any party verify the signature with the known public key.

#linux #kernel #tpm

@josh @osi For me this looked initially like as some sort of magic spell that a corp can say and then they just continue to do whatever shit they were doing before because they've just been "we're not doing evil stuff" stamped or something.

@josh @osi I had the same thoughts week ago but I tend to be a bit spiky from time to time so I thought maybe I was a bit too judgemental (which happens too often). Good to hear others reflect my first views on this. Thanks for writing this.

https://social.kernel.org/notice/AnPuVswNBKAitj9wxc

@aks Making difference between "rotten looking" and "rotten" is important especially since messy but functional is always better than clean and dysfunctional. It is a psychological more so than technical challenge to remember this ;-) https://www.joelonsoftware.com/2000/04/06/things-you-should-never-do-part-i/

@aks By following this, the rotten looking parts will get treatment within shorter timeline some commentary. This way at least not dumpsters of legacy will form...

Sometimes bad looking solution can have non-intuitive but still legit reasoning - all rotten looking is not actually rotten ;-)

These are at least my empirical learnings over the years working with open source...

Both fixes landed :-)

@aks It is sometimes hard to identify at the time. I'd suggest more like "comment on the first scratch" approach. Every time there's any issue that should lead either to:

1. A new inline comment
2. A new test case

If you start to seek appropriate places while implementing a feature, that can lead to over-saturation of comments, which dissolves the important ones.

PR for 6.12-rc7 with a fix for recently reported bug:

1. https://lore.kernel.org/linux-integrity/D5CYH0IJXX72.35A25M1YICZRP@kernel.org/T/#u
2. https://bugzilla.kernel.org/show_bug.cgi?id=219383

This bug for early weeks of the current release cycle has already landed: https://bugzilla.kernel.org/show_bug.cgi?id=219229

Right now that I don't do kernel as my main job I prioritize users instead kernel developers when picking fixes for during the cycle PR's :-) Other fixes can wait until 6.13 PR.

#linux #kernel

@ljs reminds me of wonderful adventures of nils holgerson

@ljs background picture material love it

@mrmasterkeyboard This configuration allows me to even build new version of OpenSBI for every build, i.e. I get end-to-end open source stack built by BuildRoot, and has one cable less (no separate power cable) than Raspberry Pi.

The next step I'm planning to improve this is adding JTAG probe into it :-) I have one waiting for this already.

@mrmasterkeyboard

I don't know what you mean by "green board" and "black board" but this is:

1. VisionQuest 2 RISC-V board
2. A shield providing RS-232 through USB ordered from AliExpress
3. LetsTrust TPM SPI module (Infineon SLB 9672)

I do most of kernel testing in QEMU ATM but this is my bare metal choice because single USB cable gives both power and serial link and board has jumpers to configure it to SDIO mode (i.e. all stages read from provided SD card). RISC-V is a bit irrelevant here but gives confidence that changes work in multiple platforms and not just on x86. And also slowness is a feature for catching performance regressions.