4 ms·

But no one is hiding the bug this "fixes". If this bug + something else can be a hypervisor escape, well that's too bad for the AWS of this world, but I don't s

But no one is hiding the bug this "fixes". If this bug + something else can be a hypervisor escape, well that's too bad for the AWS of this world, but I don't see how this patchset would leak the "something else" we don't know about?

KirinDave 9y ago
It's not unusual for folks implementing popular OSs to get heads up that some sort of Significant Security Issue is being discussed by other vendors, including receiving advice. I consider this newsworthy because many very good security engineers in my feed agree it is.
rurban 9y ago
No, not AWS. Xen was called safe. All the other KVM providers and normal linux servers in Intel are called out. arm, sparc, s390 were called out as safe, as they provide two seperate translation table registers, only intel provides only one.
- amluto 9y ago
  I don't think ARM64 works the way you think it does. On s390, there's a register for user-initiated access and a register for kernel-initiated access. On ARM64 (AIUI), there's a register for low (user) addresses and a register for high (kernel) addresses. So kASLR timing leaks on s390 shouldn't happen in the first place unless the TLB tagging itself is rather silly, but ARM64 has no inherent protection. What ARM64's system does provide is a much simpler way to do a PTI-style pagetable split by twiddling the high address register at entry and exit.
  - numbsafari 9y ago
    Isn’t Amazon moving off of Xen? Perhaps their involvement is limited to those working on their new KVM-based hypervisor? They also recently dropped their dedicated host requirement for HIPAA customers (to catch up with GCP).
wilun 9y ago
What do you think this fixes? Tiny info leak about kernel addresses? There are still other more reliable ways to get that (even if there is active work to remove those), and I don't believe this would yield to a semi-rushed patch with 5% mean and sometimes 30% performance degradation impact enabled by default, with Linus himself expecting to be backported (rarely to never seen on a change of this importance, and would make no sense given older kernels are even more full of simpler kaddr info leak) This fixes something bigger than Intel could not fix by microcode update...

KirinDave 9y ago

It's not unusual for folks implementing popular OSs to get heads up that some sort of Significant Security Issue is being discussed by other vendors, including receiving advice. I consider this newsworthy because many very good security engineers in my feed agree it is.

rurban 9y ago

No, not AWS. Xen was called safe. All the other KVM providers and normal linux servers in Intel are called out. arm, sparc, s390 were called out as safe, as they provide two seperate translation table registers, only intel provides only one.

amluto 9y ago
I don't think ARM64 works the way you think it does. On s390, there's a register for user-initiated access and a register for kernel-initiated access. On ARM64 (AIUI), there's a register for low (user) addresses and a register for high (kernel) addresses. So kASLR timing leaks on s390 shouldn't happen in the first place unless the TLB tagging itself is rather silly, but ARM64 has no inherent protection. What ARM64's system does provide is a much simpler way to do a PTI-style pagetable split by twiddling the high address register at entry and exit.
- numbsafari 9y ago
  Isn’t Amazon moving off of Xen? Perhaps their involvement is limited to those working on their new KVM-based hypervisor? They also recently dropped their dedicated host requirement for HIPAA customers (to catch up with GCP).

wilun 9y ago

What do you think this fixes? Tiny info leak about kernel addresses? There are still other more reliable ways to get that (even if there is active work to remove those), and I don't believe this would yield to a semi-rushed patch with 5% mean and sometimes 30% performance degradation impact enabled by default, with Linus himself expecting to be backported (rarely to never seen on a change of this importance, and would make no sense given older kernels are even more full of simpler kaddr info leak) This fixes something bigger than Intel could not fix by microcode update...