6 ms·

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

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.

saurik 9y ago
I personally think "the price of cloud computing just went up 5-10%" is "a big deal" and not some niche scenario.
- jacksmith21006 9y ago
  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.
Xylakant 9y ago
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.
- cookiecaper 9y ago
  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.
  - fpoling 9y ago
    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.
    - cookiecaper 9y ago
      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...
      - Xylakant 9y ago
        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.
        cookiecaper 9y ago
        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.
      - fpoling 9y ago
        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.
- jorgec 9y ago
  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.
jorgec 9y ago
I agree. For most cases, the fix is worst than the solution.
deleted 9y ago
[deleted]
1_2__4 9y ago
Spoken by someone with no experience with things like ISO and SOC2 certification. Go ahead and try to explain to your auditors this year how all your internal controls around privilege escalation and separation of duties are known to be exploitable (and thus rendered useless) due to multiple widely-publicized attacks but it's not important. See how they like your answer.
x0x0 9y ago
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.
- craigyk 9y ago
  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?

saurik 9y ago

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

jacksmith21006 9y ago
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.

Xylakant 9y ago

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.

cookiecaper 9y ago
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.
- fpoling 9y ago
  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.
  - cookiecaper 9y ago
    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...
    - Xylakant 9y ago
      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.
      - cookiecaper 9y ago
        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.
    - fpoling 9y ago
      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.
jorgec 9y ago
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.

jorgec 9y ago

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

deleted 9y ago

[deleted]

1_2__4 9y ago

Spoken by someone with no experience with things like ISO and SOC2 certification. Go ahead and try to explain to your auditors this year how all your internal controls around privilege escalation and separation of duties are known to be exploitable (and thus rendered useless) due to multiple widely-publicized attacks but it's not important. See how they like your answer.

x0x0 9y ago

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.

craigyk 9y ago
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?