@mpdesouza @corbet @krzk I appreciate this service too. Now that I write majority of code elsewhere and mostly just review/test for Linux, it's nice to get a bit of credit still :-) Gives a small boost motivation and feeling of being part of community and thus contribute more in some other season of "story of my life" again.

@mpdesouza I've been writing a feature patch set for kernel for first time for a long time and in that I've noticed that LSP is really helpful to on navigating around the tree :-) Makes it considerably a faster process because before I would have used mostly https://elixir.bootlin.com/linux/v6.11.8/source. For bug fix I might grep like a portion of a log message string or something like that.

One non-LSP thing I've liked once I got over how weird it was first, is multi-cursor/select approach for search replace. If ":q" was important for Vim, for Helix the important key stroke to keep in mind is IMHO "," because it can be trippy if you accidentally end up to the multi-cursor mode ;-)

@krzk lol did not know i was a "tested-by regular" ;-) not in this stats but looked few older and seems to be that it is my the most common list.

@mpdesouza With Rust it becomes quite difficult to navigate in large projects unless there is LSP or similar. With kernel you can go far with git grep ;-) The reason is that even a simple Rust project can connect to hundreds of crates through the dependency graph as the app executable model of Rust is essentially huge static blob.

Last year, for each of six Linux kernel releases - v6.7, v6.8 ... v6.12 - I was topping the list of most active contributors. This consistency led to a more interesting stat: I am one of the most active Linux kernel contributors for this period (and I don't count Kent here as he just dropped stuff out of tree... and then developed things to his own tree without review or mailing list collaboration) with 1339 commits upstream.

I am however more proud of another impact I made: I am one of the most active reviewers of the last one year of Linux kernel development. Reviewing takes a lot of time, a lot of iterations, a lot of patience, a lot of template answers and results with only "some" of reviewed-by credit going to Linux kernel git history. Yet here I am: ~1000 reviewed-by credits for last year v6.7 - v6.12 Linux kernel.

Source, LWN.net:
https://lwn.net/SubscriberLink/997959/377cf2f076306247/

@kernellogger yeah, it's pretty trivial. also machine owner keys used for both system and user could in principle live inside TPM (which would kind of logically make sense as it identifies the machine).

@antirez Latest meaningful place for discussion I'm aware of: IRC

@shenki @kernellogger mok is actually somewhat easy

@kernellogger After doing this I learned about efikeygen but since this does the right thing with basic tools I'm not sure if it makes sense to complicate it with extra shenanigans :-) Not going to fix a working solution I guess.
One thing that would be nice if Fedora could sign installed Linux images with a custom MOK key. That would make all seamless. It's a better solution than doing it in build.

@kernellogger and it boots:

$ mokutil --sb-state
SecureBoot enabled

~ main ⇡
$ mokutil --list-enrolled
2bb010e24d fedoraca
f5476e8353 Secure Boot Signing Key

@kernellogger

Finally I wrote a small script:

#!/usr/bin/env bash

sudo pesign \
  --certificate 'Secure Boot Signing Key' \
  --in "$1" \
  --sign \
  --out "$1.signed"
sudo mv -v "$1"{.signed,}

Then I signed kernel-rt and:

$ sudo pesign --certificate 'Secure Boot Signing Key' --show-signature --in /boot/vmlinuz-6.12.0-0.rc7.20241113gtf1b785f4.459.vanilla.fc41.x86_64+rt
[sudo] password for jarkko: 
---------------------------------------------
certificate address is 0x7ffb85b05208
Content was not encrypted.
Content is detached; signature cannot be verified.
The signer's common name is Red Hat Test Certificate
No signer email address.
Signing time: Wed Nov 13, 2024
There were certs or crls included.
---------------------------------------------
certificate address is 0x7ffb85b05900
Content was not encrypted.
Content is detached; signature cannot be verified.
The signer's common name is Secure Boot Signing Key
The signer's email address is jarkko.sakkinen@siltakatu.com
Signing time: Fri Nov 15, 2024
There were certs or crls included.
---------------------------------------------

@kernellogger My certificate config as input was:

[ req ]
default_bits            = 4096
distinguished_name      = req_distinguished_name
x509_extensions         = v3
string_mask             = utf8only
prompt                  = no

[ req_distinguished_name ]
countryName             = FI
stateOrProvinceName     = Pirkanmaa
localityName            = Tampere
0.organizationName      = Siltakatu Solutions Oy
commonName              = Secure Boot Signing Key
emailAddress            = jarkko.sakkinen@siltakatu.com

[ v3 ]
subjectKeyIdentifier    = hash
authorityKeyIdentifier  = keyid:always,issuer
basicConstraints        = critical,CA:FALSE
extendedKeyUsage        = codeSigning,1.3.6.1.4.1.311.10.3.6
nsComment               = "OpenSSL Generated Certificate"

@kernellogger This how you do it. Then it is just matter using the name as reference in the spec for that attribute of which name I cannot recall ATM. In this case: ""Secure Boot Signing Key"

Great, I made it. Created my own MOK key in Fedora:

$ sudo certutil -d /etc/pki/pesign -L

Certificate Nickname                                         Trust Attributes
                                                             SSL,S/MIME,JAR/XPI

Secure Boot Signing Key                                      Pu,Pu,Pu

Steps:

openssl req -config ./MOK.cnf -new -x509 -newkey rsa:4096 -nodes \
            -days 36500 -outform DER -keyout "MOK.priv" -out "MOK.der"
sudo certutil -A -i MOK.der -n "Secure Boot Signing Key" -d /etc/pki/pesign/ -t "Pu,Pu,Pu"
sudo openssl pkcs12 -export -out MOK.p12 -inkey MOK.priv -in MOK.der
sudo pk12util -i MOK.p12 -d /etc/pki/pesign

And yeah obviously you also want to do:

sudo mokutil --import MOK.der

#fedora #linux

I think in theory it could be possible to make static eBPF, i.e. take the source tree compile eBPF as inline modifications. I.e. mimic "printk debugging" with eBPF.

When kernel testing e.g. with BuildRoot this would be more lean than actual eBPF.

"git workspace" gives a reference model for clone snapshotting.

Usually when fixing kernel bug or doing some improvement to kernel, adding a few temp printk's is still imho the king because kernel compiles in no time. Dynamic tracing tools do not support this workflow very well. They support well debugging exactly live systems, which is totally different use case.

#linux #kernel #ebpf

Compiling > 2100 sub-crate dependency Rust project with hot sccache (< 5 misses), I noticed that my X1 ThinkPad finishes about 30 minutes and Mac M2 Pro in 10 minutes.

It gives a rough ballpark factor for single core performance against i7-1260P
given that compilation (which distributes best) takes quite insignificant portion of the time, and most is spent in linking...

enforced to use matrix at work so really have had to do research on this because overall the quality is not great :-)

This is the only all rounds good Matrix client I'm aware of: https://iamb.chat/index.html It is terminal but is both multi-account and a separate thread view (and all E2EE crap).

From graphical ones GNOME projects Fractal is otherwise great except the lack of thread view.

#matrix

lol

@vbabka @sima good to be aware of this +1