@lauriewired

@lauriewired

2026-10-02 — saved image

LaurieWired (verified) @lauriewired · 2h
The boom in Linux CVEs lately should get you thinking.

Surely, given a finite codebase, there are also a finite number of bugs / unintended behavior, thus, a finite amount of vulnerabilities. Theoretically, a "solvable" problem. Right?

Well...not at all actually.

It gets a bit philosophical, but there's the concept of "weird machines".

A weird machine is an accidental computer located inside of another computer program. Quite a few exploits (e.g. anything ROP) falls into this category, where the attacker's instruction set consists of fragments of the original software.

Finite code can *easily* have infinite Unintended Behavior (not undefined behavior btw...that's a very different thing). Weird machines don't even have to be Turing complete to be, really, really powerful!

Even if you have a million superhuman AI coders and fuzzers thrown at the Linux kernel, you quickly hit halting-problem-esque uncomputable states. The concept of patching every possible bug until none remain isn't possible, because we can't often correctly define what a "bug" even is.

Now, can you make a kernel that truly has zero weird machines relative to a formal specification? ....yes, but it wouldn't look like Linux. It'd look more like sel4, VxWorks, or (shudder) INTEGRITY-178.

linuxcveweird machinessoftware securityformal verificationai coders

@lauriewired

2026-09-13 — saved image

LaurieWired @lauriewired · Sep 12
If you're a CS student, I'd suggest writing your thesis around SDCs (silent data corruptions) and efficient algorithmic fault tolerance.

We're quickly going to need to accept the (un)reliability of computing systems again!

Every indicator (density, lower voltage gating, raw scale) is moving towards SDCs becoming a more serious issue over the next decade. And let's not forget when all of this stuff starts to go in space and we have to deal with cosmic events on "not-super-rad-hard" CPUs+GPUs!

No, you can't solve it all in hardware. It's prohibitively expensive; and the long tail of "potential SDCs" is just too long. One bad apple ruins your pie. One bad GPU can inject repeated corruptions into otherwise noise-tolerant workloads (*cough* AI training).

If you continuously accept a corrupted value from say...a bad tensor core, that bad value can quickly spread across the whole cluster. If it happens again and again and again and no one notices; it's like putting a little bit of spin on a bowling ball. Eventually, the overall trajectory ends up widely different!

When you start to imagine this stuff being in space (cosmic bit flips), and quantized(!), each remaining bit carries more critical information. Long term we're going to have to accept clever, low-overhead software algorithms.

Accepting say, a ~3% perf loss can be *absolutely* worth it if it increases your odds of detecting a mercurial core enough! [cut off]

silent data corruptionfault tolerancehardware reliabilitygpuai trainingspace computingmercurial cores

@lauriewired

2026-02-07

twitterdata visualizationchernoff facesfinancecognitive science