2 ms·
So I agree with the principle that a lot of time is a lot of time. Inversely, though, I'd argue that Meltdown is a relatively small problem! It's strictly arou
by rtpg 9y ago
So I agree with the principle that a lot of time is a lot of time.
Inversely, though, I'd argue that Meltdown is a relatively small problem! It's strictly around memory usage, cache, and calling patterns. There's not a lot of systems at play, though there's the hard "figure out which order of instructions gets the state machine in a dangerous state" problem. There's a lot less coordination involved than, say, a system call bug that would subtly return the wrong answer half the time and you know that programs sometimes rely on this and others crash because of it.
Some things are hard, other things are hard but at least they're basically math, and math has a bit more determinism involved. Imagine if UX design or debugging strategies could always be broken down into state machines!