6 ms·
Spectre chip security vulnerability strikes again; patches incoming
- ythn 8y agoI hope there's a way for users to disable these patches. I for one would rather have a fast processor that does speculative execution than one that takes a significant N% performance hit but is armored against speculative attacks. Security compliance is becoming more and more like a ball and chain shackled to our legs. I expect security to slowly eat up a bigger and bigger share of processing power which translates to more sluggish chips, more sluggish software, etc.
- zedder 8y agoHi, could you please explain this further? I always assumed that if a program or chip is vulnerable then it is not operating as intended and must be patched quickly. You’re suggesting that if a security vulnerability is patched and it removes a feature (in this case, processor performance) we should forgo it. Am I understanding correctly?
- hackinthebochs 8y agoI think the point is that "security" isn't absolute, its always relative to some threat model. But if untrusted code isn't a part of your threat model then you might prefer the performance benefits.
- tlb 8y agoThe vulnerability allows a user process to see data from the kernel, which could let it take over the machine. That's a huge problem on a multi-user machine, but not on dedicated servers that only run code the owner wants to run.
- blattimwind 8y agoI don't really care about malicious user-mode applications being able to take a peek at kernel memory on my desktop machine, because there are effectively two users: me, who often becomes root locally and remotely, and root. I do care about random websites being able to do the same (obviously). Due to "Linux security properties" any random user-mode application is me and therefore already root and does not require an exploit to read kernel memory. The user-root-distinction is all but the thinnest of veils on a desktop Linux.
- zeveb 8y agoI disagree — security is a sina qua non for a functioning system. Leaking information between different processes is simply incorrect, even on a single-use system.
- adrianN 8y agoFor systems where you can guarantee that no untrusted code runs I'd rather have the faster processor.
- my123 8y agoLinux actually applies a mitigation that is applied for sandboxed processes only by default to mitigate Variant 4. For Variant 3A, well, it's another Meltdown and will be handled as such.
- pdpi 8y agoSure — security is, in abstract, important. The security requirements of different systems vary, though. I'm much more worried about things like this in edge machines that talk to the public than some backend data-processing pipeline that doesn't talk to the outside world at all.
- nonbel 8y agoAt least AMD recommends you don't need the patch: >"Based on the difficulty to exploit the vulnerability, AMD and our ecosystem partners currently recommend using the default setting that maintains support for memory disambiguation. We have not identified any AMD x86 products susceptible to the Variant 3a vulnerability in our analysis to-date." https://www.amd.com/en/corporate/security-updates https://www.amd.com/en/corporate/security-updates I couldn't (quickly) find a similar comment from intel.
- my123 8y agoIn the Linux kernel, the mitigation is applied for sandboxed processes, which makes sense. Note that no microcode updates are needed for AMD, while they're needed for Intel. https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=3b78ce4a34b761c7fe13520de822984019ff1a8f https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...
- hinkley 8y agoThese performance regressions are getting a bit depressing. Is there some other way we could architect chips or operating systems that would allow these branch predictors to go full bore instead of having to hamstring them? When this story first broke I know we talked a bit about the impetus to move code out of the kernel into user land.
- goalieca 8y agoWe could have shorter pipelines ;)
- Filligree 8y agoWhich would hamstring performance.
- goalieca 8y agoyeah. it was a half-joke + half-serious. Would be interesting to see the performance of branch predictor fix vs just having a short pipe.
- titzer 8y agoShorter pipelines don't fundamentally change anything about speculative vulnerabilities. Longer pipelines allow faster clock rates, but that is not the problem here. Speculative vulnerabilities are because branch prediction is needed to get the CPU looking far enough in the future to feed all the functional units so that it can execute not just one instruction per clock, but 4 (actually u-ops, but you get the picture). To do that, you need to know the execution path far into the future. That is not really related to the pipeline depth at all.
- goalieca 8y agoWell yeah, but the implied point is that there must be some depth and workload where having a branch predictor fast or slow makes much less difference.
- gruez 8y agoprevious discussion: https://news.ycombinator.com/item?id=17121811 https://news.ycombinator.com/item?id=17121811 (172 points by brandon 19 hours ago | 20 comments)
- CrankyBear 8y agoIt's not a dupe. This article gathers up info from multiple and later sources--Intel, Red Hat, etc. and how to deal with it--not simply the first mention of the problem.