Notices by Kees Cook :tux: (kees@fosstodon.org)

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

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

Dear C Lazy Web,

How do I define an array of nonstring char arrays?

just a char array, valid:
char str[4] __attribute__((nonstring)):

array of char arrays, cursed:
char multi[10][4] __attribute__((nonstring));

I've tried typedefs and moving the attribute around. No luck. What am I missing?

Here's a godbolt:
https://godbolt.org/z/4Mb61heG1
I'd want to see a warning for both strlen() instances...

@hanno @yossarian Ah, I may have it backwards then, but '[' remains the safe one. 😅

@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/[

@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.

It's nice that an LLM found a bug, but it's also trivially mitigated with the bounds safety sanitizer with virtually no overhead. Your regular reminder to build all production C projects with "-fsanitize=bounds -fsanitize-trap"

int aIdx[7]; // compiler knows the size of this array
...
int iCol; // if this should not be negative, why is this "int"?
...
aIdx[iCol] = i; // build with bound checking!

https://infosec.exchange/@ifsecure/113408455787473153

@bagder @hikhvar @dascandy It's still running, but here's through 2018...

@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

@bagder @hikhvar @dascandy LOL. 102 Linux kernel tags, averaging 3 minutes per blame run (so far). 5 hours to generate the data. O_O

@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! :)

@ljs @kernellogger @vbabka Why? Just use linux-next. Nothing should go in it that's not ready to go to Linus. Who is it that isn't testing -next? I'm always testing there. All the CIs I see reporting to lkml are testing -next. I genuinely didn't understand what's missing. -next is for testing. Do people need to be reminded to test on _copies_ of their data/images/workloads?

@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.

@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.)

@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.

@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.

@KernelRecipes The continuity across upstream messaging has been clear since (probably before) 2017. Same observations then too: https://youtu.be/RKadXpQLmPU#t=2796
"If you are not using a stable / long-term kernel, your machine is insecure" - @gregkh

@KernelRecipes Followed up by my more nihilistic take:
https://youtu.be/b2_HAH2kX04#t=373

Bottom 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. :)

Is anyone running Clang-built #riscv or #powerpc #Linux kernels in production? If so, please let me know.

@hawkes "build systems are a perfect mix of inscrutability and expressiveness" 💯