Hacker News Reader

Comment by jnordwick | Hacker News Reader

And this is only going to be for installations that actually care about this level of security, so mostly just shared infrastructure/serverless/cloud. Internal systems aren't going to need the mitigation.

I think people are blowing this way out of proportion.

View on HN

I personally think "the price of cloud computing just went up 5-10%" is "a big deal" and not some niche scenario.

Thing is I/O fees are contractual so Amazon has to suck up the increased cost or try to pass it somehow to Intel.

But computer instances the extra cost will be on the customer and it is hard to see Amazon taking the PR hit and not somehow trying to put it on Intel.

Like “all installations on AWS, GCE, DO and so on are affected? Even semi-private clouds might need mitigations since people rely on VMs as a security boundary. So yes, this is a big deal.

These test results do not show the real effect of PTI, they only show the effect of enabling pti within a virtualized kernel. That's still useful because a lot of people are going to be enabling it (even though the value of this seems dubious), but real tests showing the approximate performance loss would need to happen on host hardware.

Meltdown on Linux allows to read all physical memory, not only the kernel data. The defence against it is only dubious if one does not rely at all on process isolation as extra layer of defence.

I understand that, but I don't know that either Spectre or Meltdown needs to be mitigated within the context of a KVM guest running on a host with mitigations. They are timing attacks, and virtualization may incur enough overhead/latency to make them infeasible (I don't know if it does or not, I haven't tested).

Also, theoretically, the KVM driver and/or QEMU could be updated to block speculative execution attacks specific to guest passthrough, though admittedly I haven't done any KVM or VT-x hacking so I don't know its intricacies; maybe this wouldn't work?

With a host that is using new vendor microcode to disable branch prediction within unsafe contexts (IBRS as a global alternative to retpoline, or IBPB), speculative execution attacks may be sufficiently mitigated at the host level without necessitating additional mitigation at the guest level.

I'm not sure if anyone who doesn't work at Intel knows that for sure yet, since it seems that some people are still trying to figure out how to get the new microcodes...

Sure, a VM running on a patched host might not need extra mitigation, but the host mitigation won’t magically be free, so running tests in a VM to get a rough idea of the impact is still a good idea.

Yeah I agree, but these tests can't show the cost without the base layer of mitigation (since at least PTI should be in effect across all instances at Amazon), so they're incomplete. The "unmitigated" version have at least the host-level mitigations. I'd love to know more definitively whether host-only mitigation is enough.

Host measures should stop the attacks between VMs, but they will not stop attacks within a VM. A busy VM threads may run on their physical cores/threads uninterrupted by the host. Flashing branch prediction by the host on a context switch then does not happen so this variant of Spectre still works.

The host measures will not protect against another variant of Spectre or Meltdown within the VM even if the host performs context switches. The frequency of switches is just too low to disrupt a single cycle of the attack. So the attack will be just slowed down. In addition, as processes within VM have both access to high-resolution timer and CPU performance counters, the attack can detect context switches allowing for simpler recovery from them.

But since when a VM is used as a workstation?. AFAIK we know that this vulnerability could be executed via javascript. If the browser is safe then we are safe about it without patch-hacking the kernel.

Here's an example, though -- a former employer has dealt with scaling by staying just this side of what top-of-line hardware can support in lieu of going distributed. Because it massively simplifies ops / possible failure modes of dist systems that simply aren't present in single node systems. I'm still on a slack with them and they're very unhappy. They don't have this type of available overhead available on their pg or redis instances.

Are they running on bare metal? I'd say don't patch and only run pg and redis on the machine. They should still be secure, no?

I agree. For most cases, the fix is worst than the solution.

Reply on news.ycombinator.com