5 ms·
I 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 sign
by ythn 8y ago
I 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...