Greg K-H
Posts
244Following
83Followers
2587
Greg K-H
gregkh
In non-CVE news, here's some fun hardware I got while visiting Hong Kong. It's not the snappiest laptop I've ever used, but it holds potential!
Kernel source is all public (there's a 6.1.y and 6.6.y tree at the moment), hopefully will start working on getting it all merged upstream to make it a proper platform for others to use.
Kernel source is all public (there's a 6.1.y and 6.6.y tree at the moment), hopefully will start working on getting it all merged upstream to make it a proper platform for others to use.
4
9
33
Greg K-H
gregkh
@kurtseifried Note, 3000 includes the "old" things we are backfilling from the GSD database, not just the ones that have shown up this year since we started in February. So while 3000 sounds big, if you are using a modern kernel (i.e. something from this year), it's only 1500+ issues to be assigned so far.
Sorry to nit-pick, just wanted to be specific as 3000 in 6 months originally seemed like a lot to me before I went back and looked at these numbers.
Also, for those who want to play along on their own, just clone our vulns.git repo at git.kernel.org and look at the information directly there yourself, it's all being reviewed and assigned in the open, unlike other projects...
Sorry to nit-pick, just wanted to be specific as 3000 in 6 months originally seemed like a lot to me before I went back and looked at these numbers.
Also, for those who want to play along on their own, just clone our vulns.git repo at git.kernel.org and look at the information directly there yourself, it's all being reviewed and assigned in the open, unlike other projects...
1
0
4
Greg K-H
gregkh
Slide from a college lecture about Linux this year. While it's not exactly wrong, I don't think it is all that complete, and accidentally humorous. I feel for the kids...
5
3
29
Greg K-H
gregkh
Thanks to @jstultz for showing that the monstrosity of USB A-C-A with a magnetic C connector in the middle actually works! Saves me constantly having to plug/unplug my microphone and camera every other day into my well-worn USB hub.
John did it much better with one less adapter than I so this stack could be smaller if needed, but this is all I could find locally.
John did it much better with one less adapter than I so this stack could be smaller if needed, but this is all I could find locally.
6
16
38
Greg K-H
gregkh
There's been a long nerd-sniping thread recently here from @monsieuricon where email message-ids were being discussed and generated in semi-interesting ways that ended up detouring me and @brauner into writing up competing python vs. perl scripts to get `git send-email` to properly use our new bespoke message ids:
https://social.kernel.org/notice/AU5IphRPUsQvvkx732
But why does any of this matter? As most everyone knows, Linux kernel development happens through email, and the Message-Id of an email is a unique identifier that is used to track messages in our patch handling tools and archives (see https://lore.kernel.org for the archives.) By crafting shorter-but-still-unique message ids it's easier to reference those messages in other places, and using words is just prettier overall than random UUID values (https://i.redd.it/64gl4t9s52ra1.jpg for an example)
Bonus to all of this is that people don't realize that most of the patches we send out are actually signed and can be validated as coming from the person that sent them. The tool we use for that looks at the body of the email, and a small subset of the Header tags in the email. By providing to the tool our custom Message-Id, that adds yet another portion of the email that is now able to be signed and validated, providing a tiny bit more security overall in the patch submission processes (very very tiny, I know, but it's real, as I found out when I submitted a patch with a broken message-id from what was signed and our tools caught it.)
Anyway, all of that is a long way of showing off a tiny core change to the kernel that allows some core structures to be moved to read-only memory that I've been working on for a few months now. Here's the last portion of that work being sucked off of the email archives and validated as coming from me:
https://social.kernel.org/notice/AU5IphRPUsQvvkx732
But why does any of this matter? As most everyone knows, Linux kernel development happens through email, and the Message-Id of an email is a unique identifier that is used to track messages in our patch handling tools and archives (see https://lore.kernel.org for the archives.) By crafting shorter-but-still-unique message ids it's easier to reference those messages in other places, and using words is just prettier overall than random UUID values (https://i.redd.it/64gl4t9s52ra1.jpg for an example)
Bonus to all of this is that people don't realize that most of the patches we send out are actually signed and can be validated as coming from the person that sent them. The tool we use for that looks at the body of the email, and a small subset of the Header tags in the email. By providing to the tool our custom Message-Id, that adds yet another portion of the email that is now able to be signed and validated, providing a tiny bit more security overall in the patch submission processes (very very tiny, I know, but it's real, as I found out when I submitted a patch with a broken message-id from what was signed and our tools caught it.)
Anyway, all of that is a long way of showing off a tiny core change to the kernel that allows some core structures to be moved to read-only memory that I've been working on for a few months now. Here's the last portion of that work being sucked off of the email archives and validated as coming from me:
0
14
29
Greg K-H
gregkh
The 4.9.y kernel is finally end-of-life, it is gone from the tracking board.
2
101
193