Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

This is about as trenchant an analysis as "when will people realize that the problem is computers?". The constraint we work with when securing systems is that we don't get to rearchitect the entire world; that's what makes systems security hard.


Yes, that is indeed the original sin. See Morris’s Three Laws Of Computer Security: do not own a computer, do not turn it own, and do not use it.


> when will people realize that the problem is computers?

That's how I feel though some days, tbh.


As a security guy, you’re stuck with the world as it is. But as a mere user, I can certainly complain about the direction computing has gone.


Of course. I'm just saying, it's a banal point to make, and certainly not one that will produce a useful, interesting, or curious conversation.

15 seconds later

(I'll admit: I didn't even notice until just now that it was you who'd made the parent comment, and I feel maybe a little bad about the tone I took. But I'm still right!)


Systems security people can complain too, but just like they can’t change things neither can you :(


At least don't share the same core. There's gotta be some limit.


IIUC on Linux you can enable CONFIG_SCHED_CORE/PR_SCHED_CORE to realize that idea. [1] Some caveats may apply...

edit: to be clear, I just learned about retbleed five minutes ago, so I'm definitely not promising core scheduling mitigates it. I do think core scheduling is a good idea in general.

[1] https://www.kernel.org/doc/html/latest/admin-guide/hw-vuln/c...


Is that even enough? Hyperthreading let some of the earlier spectre exploits work faster, but as long as there's some shared cached between two cores (L2 or L3), that's enough for timing variations to leak what's in that cache afaik. Maybe it's enough for this attack (unsure), but I don't think it solves speculative side-channel leaks in general.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: