Hacker News Reader

Comment by ythn | Hacker News Reader

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.

View on HN

At 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

I couldn't (quickly) find a similar comment from intel.

In 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/lin...

Hi, 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?

I 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.

The 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.

I 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.

I 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.

For systems where you can guarantee that no untrusted code runs I'd rather have the faster processor.

Linux 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.

Sure — 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.

Reply on news.ycombinator.com