Posts by kees@fosstodon.org
(DIR) Post #AmIS2xkODxEdnN6YIy by kees@fosstodon.org
2024-09-23T13:39:28Z
1 likes, 0 repeats
@KernelRecipes Followed up by my more nihilistic take:https://youtu.be/b2_HAH2kX04#t=373Bottom line remains the same: we have to eliminate bug classes. I'm really excited by all the work that continues on this front between fixing the C language itself and the adoption of Rust. We continue to make steady progress, but can always use more help. :)
(DIR) Post #AmIYTxaTWgBuqKiwLY by kees@fosstodon.org
2024-09-23T13:50:07Z
1 likes, 0 repeats
@KernelRecipes Sometimes people need reminding that CVEs are just a stand-in for the real goal: fixing vulnerabilities. The point of "the deployment cannot have any CVEs" isn't an arbitrary check list. The goal is to get as close as possible to "the deployment cannot have any vulnerabilities".The Linux Kernel CNA solves the "tons of false negatives" problem (but creates the "a few false positives" problem), but the result is a more accurate mapping from vulnerabilities to CVEs.
(DIR) Post #AmIYTybZk4fK02FKhU by kees@fosstodon.org
2024-09-23T13:55:56Z
0 likes, 0 repeats
@KernelRecipes So the conclusion from this is that anyone saying "we can't keep up with all the CVEs" is admitting that they can't keep up with all the current (and past!) vulnerabilities present in the kernel.Either they don't have a threat model, can't triage patches against their threat model, or can't keep up with stable releases due to whatever deployment testing gaps they have.There are very few deployments I'm aware that can, honestly. This is hardly new, but now it is more visible.
(DIR) Post #AmIYTzPYkEeEV3dFbs by kees@fosstodon.org
2024-09-23T14:06:19Z
0 likes, 0 repeats
@KernelRecipes But this is why I've been saying for more than a decade, and others have said for way longer, that the solution is eliminating classes of flaws.Bailing water out of the boat is Sisyphean without also patching the holes in the hull. But since we're already in the water, we have to do both. And the more we can fix the cause of the flaws the less bailing we need to do; so more Rust, safer C.I look forward to finding design issue vulns instead of the flood of memory safety issues.
(DIR) Post #AmKgaaFHtdPGQVP1lo by kees@fosstodon.org
2024-09-24T15:22:03Z
0 likes, 0 repeats
@pavel @KernelRecipes At the LPC CVE BoF, in a room filled with people who care deeply about this topic, there appeared to be consensus that the CNA has traded many false negatives for a few false positives. (I.e. we are now closer to the imagined objective reality of a 1:1 mapping between fixes and CVEs.)In the past, with distros and researchers mostly causing the CVE assignments, the implied threat model was that of a distro, and didn't represent other models. (But still missed fixes.)
(DIR) Post #AmKgab3yr9xKxj7Vmi by kees@fosstodon.org
2024-09-24T15:28:18Z
0 likes, 0 repeats
@pavel @KernelRecipes I think of the CNA as doing a first pass at CVEs, and then each deployment can continue triage based on their threat model. This is how it's always been, it's just that severity triage has been moved closer to where it is needed: with those that have a threat model to apply. What has changed is that there isn't yet a place for common threat models to share triage. This used to be the CVEs themself, but that left out all the other threat models and missed tons of fixes.
(DIR) Post #AmKgabfYbS0uqGhWM4 by kees@fosstodon.org
2024-09-24T15:32:11Z
1 likes, 0 repeats
@pavel @KernelRecipes Deployments always had an obligation to evaluate vulnerabilities and fix them, but now it has become unavoidable and threat model mismatches are glaringly obvious.Yes, it is possible that for a given threat model, there are now a ton of CVEs that will need to have their severity labeled as "don't care". But this was always true -- but no one triaged fixes, they triaged against the prior CVEs, which were a small subset of the distro threat model. Lots of fixes got missed.
(DIR) Post #AnZoJClOLcSXoNRi76 by kees@fosstodon.org
2024-10-31T18:18:30Z
0 likes, 0 repeats
@bagder @hikhvar @dascandy Oh this is really nice! You've inspired to generate this for the Linux kernel. The git blames are running now... I parallelized it, but it's still going to take a while! :)
(DIR) Post #AnZoJDSzjVKzzbqX4q by kees@fosstodon.org
2024-10-31T19:49:39Z
1 likes, 0 repeats
@bagder @hikhvar @dascandy LOL. 102 Linux kernel tags, averaging 3 minutes per blame run (so far). 5 hours to generate the data. O_O
(DIR) Post #AnZoR5XT5msRingznk by kees@fosstodon.org
2024-10-31T20:15:09Z
1 likes, 0 repeats
@bagder @hikhvar @dascandy Not sure if you want this too; I ended up tweaking the plot's display of lines slightly with this format:set format y2 "%.0s%c"So instead of, e.g., 200000, it'll show 200k
(DIR) Post #Ana1etRCBCy3eHfgie by kees@fosstodon.org
2024-10-31T22:44:45Z
1 likes, 1 repeats
@bagder @hikhvar @dascandy It's still running, but here's through 2018...
(DIR) Post #AneAIwrtpaBQq8Yq5A by kees@fosstodon.org
2024-11-02T19:40:04Z
0 likes, 0 repeats
@kurtseifried @bagder @hikhvar @dascandy Well, lines of code are much lower, but the shape is basically the same. Here's the graph with drivers/* excluded:
(DIR) Post #AneEDYFiKBKcrcNjuq by kees@fosstodon.org
2024-11-02T23:10:56Z
0 likes, 0 repeats
@shironeko @dascandy @kurtseifried @bagder @hikhvar That's the removal of unused architectures. :) https://fosstodon.org/@kees/113415070802544502
(DIR) Post #AnfaRjUpi1rfwKa5Dc by kees@fosstodon.org
2024-11-01T17:46:08Z
0 likes, 1 repeats
@bagder @hikhvar @dascandy Okay, here's the full run.
(DIR) Post #AoGivc3MK4myPwwVii by kees@fosstodon.org
2024-11-21T12:31:37Z
1 likes, 0 repeats
@yossarian The use of '[[' is the problem. That's an evaluating comparison and is as dangerous as 'eval' (as shown). All scripts should be using just the single '['. Using '[[' is for compatibility with ancient shells.
(DIR) Post #AoGmTa9cBpFoEgl4ts by kees@fosstodon.org
2024-11-21T13:22:34Z
0 likes, 0 repeats
@hanno @yossarian Yeah this was a common recommendation long ago to "avoid bash-isms" for compatibility. Since then busybox and dash (the common non-bash "/bin/sh" instances) grew '[' support either internally or via /usr/bin/[
(DIR) Post #AoGmTbZstdrSeS3ZU8 by kees@fosstodon.org
2024-11-21T13:38:37Z
1 likes, 0 repeats
@hanno @yossarian Ah, I may have it backwards then, but '[' remains the safe one. 😅
(DIR) Post #Apa5K38RZwxGQxeucy by kees@fosstodon.org
2024-12-30T19:22:37Z
1 likes, 3 repeats
I generated a 12-character commit SHA prefix collision with the start of Linux's git history. It took about 6 hours on an RTX 3080 GPU:https://people.kernel.org/kees/colliding-with-the-sha-prefix-of-linuxs-initial-git-commit
(DIR) Post #AqESplpN38n24v3Xxw by kees@fosstodon.org
2025-01-19T02:01:57Z
1 likes, 0 repeats
Well I guess everyone everywhere will want to use -fzero-init-padding-bits=all when updating to GCC15 to avoid regressing their uninitialized variable mitigations... Why in the world would the C standard committee work to make things *less* safe by default??!Edit: this appears to be a decision on GCC's part and not a new change from the C committee. (See down-thread.)https://infosec.exchange/@edmonds/113851256533780886
(DIR) Post #AsICXUih7wk6sVKSAK by kees@fosstodon.org
2025-03-21T21:16:31Z
1 likes, 0 repeats
I decided to actually go see how hard adding __builtin_is_lvalue() to Clang would be, and it only took an evening. With that available we can set the variables passed to kfree() to NULL automatically. This should kill a subset of "dangling pointer" Use-After-Free flaws with basically no overhead and almost no refactoring in the kernel.https://lore.kernel.org/linux-hardening/20250321202620.work.175-kees@kernel.org/