We're at a stage where to be safe on x86 we need to have multiple microcode and kernel layers to be safe. At which point do we agree the performance increases over the last 20 years have been built on sand and move elsewhere?
Move where exactly? At this point x86 is the least of all evils that have respectable performance.
Understanding L1 Terminal Fault aka Foreshadow: What You Need to Know
21–30 of 119 posts
Re: Understanding L1 Terminal Fault aka Foreshadow: What You Need to Know
#22We're at a stage where to be safe on x86 we need to have multiple microcode and kernel layers to be safe. At which point do we agree the performance increases over the last 20 years have been built on sand and move elsewhere?
It's probably time for a new architecture that isn't so convoluted with decades of optimizations and iterative improvements. It's also time for a computer system with one and only one general purpose processor (no tiny CPUs in storage or "system management" or every other device) Probably something like a programming language/OS/computer system written new with a CPU based on current GPU designs.
There is nothing particularly convoluted in either meltdown or this new attack. This optimization could have happened on any other architecture.
The legacy parts have either been disabled in 64-bit mode, or they are implemented in microcode. Other architectures are not simple either, ARM64 has incredibly complicated paging for example.
Re: Understanding L1 Terminal Fault aka Foreshadow: What You Need to Know
#23We're at a stage where to be safe on x86 we need to have multiple microcode and kernel layers to be safe. At which point do we agree the performance increases over the last 20 years have been built on sand and move elsewhere?
Or use the off-brand x86 (AMD) which has had very few of these vulnerabilities be useful on it.
The off-brand that invented x86-64? :)
Re: Understanding L1 Terminal Fault aka Foreshadow: What You Need to Know
#24We're at a stage where to be safe on x86 we need to have multiple microcode and kernel layers to be safe. At which point do we agree the performance increases over the last 20 years have been built on sand and move elsewhere?
It's probably time for a new architecture that isn't so convoluted with decades of optimizations and iterative improvements. It's also time for a computer system with one and only one general purpose processor (no tiny CPUs in storage or "system management" or every other device) Probably something like a programming language/OS/computer system written new with a CPU based on current GPU designs.
> no tiny CPUs
That is far more a constraint than you think. Probably quite hard to have even a gigabit Ethernet subsystem without it.
Re: Understanding L1 Terminal Fault aka Foreshadow: What You Need to Know
#25If hyper-threading should be disabled for maximum security, this is good for AMD CPUs which maximize cores per socket. 2 months ago thread on OpenBSD and hyper-threading: https://news.ycombinator.com/item?id=17350278
Or just keep using AMD CPUs, because yet again they are unaffected https://www.amd.com/en/corporate/security-updates
Never mind that AMD sockets used to last longer (less frequent incompatible socket changes), which meant you could do longer with your motherboard. Not sure if that still is the case though.
Re: Understanding L1 Terminal Fault aka Foreshadow: What You Need to Know
#26Earlier quoted context omitted.
I'm pretty sure this attack doesn't apply to AMD, being built on the original Meltdown attack that was Intel specific. So what'll happen is Intel will change their chips to not do prefetching without also doing a permissions check like MAD does. Meltdown solved.
It's not built on meltdown. It's not about violating permissions, it's about treating the contents of a page table as valid even if the page is not present or (in the case of EPT, which is worse) also treating the physical address on the guest as a physical address on the host. However, unlike meltdown it cannot access data that is not already in the L1 cache.
I mean, the V bit, and the other contexts are just PTE permissions. It's literally the same root cause as meltdown, that page table faults occur particularly asynchronously on Intel hardware and speculation occurs past those faults.
Re: Understanding L1 Terminal Fault aka Foreshadow: What You Need to Know
#27We're at a stage where to be safe on x86 we need to have multiple microcode and kernel layers to be safe. At which point do we agree the performance increases over the last 20 years have been built on sand and move elsewhere?
There is a lot of legacy cruft in x86, but it's the devil we know. After decades of use, we are still discovering vulnerabilities, in a platform thought to be well-understood. The closest alternative would be ARM. In any case, it's a massive undertaking.
The closest alternative would be ARM
On the contrary there's SPARC, MIPS, PA-RISC, POWER and a whole heap of others that perhaps were written off prematurely. Need to move quickly tho' while some vestiges of expertise still remain.
Re: Understanding L1 Terminal Fault aka Foreshadow: What You Need to Know
#28Earlier quoted context omitted.
Or just keep using AMD CPUs, because yet again they are unaffected https://www.amd.com/en/corporate/security-updates
Never mind that AMD sockets used to last longer (less frequent incompatible socket changes), which meant you could do longer with your motherboard. Not sure if that still is the case though.
Ryzen Pro has a more stable socket.
Re: Understanding L1 Terminal Fault aka Foreshadow: What You Need to Know
#29If helpful a few Cloud Providers Responses: Google Cloud - Google Cloud's protections against this new vulnerability: - https://cloud.google.com/blog/products/gcp/protecting-agains... ) - GCE Related information: - https://cloud.google.com/compute/docs/security-bulletins - GKE Related information: - https://cloud.google.com/kubernetes-engine/docs/security-bul... Oracle Cloud - https://blogs.oracle.com/oraclesecurity/…
For AWS: https://aws.amazon.com/security/security-bulletins/AWS-2018-... (Disclaimer: I work at AWS, but I am not linking this in any sort of official capacity. I don't know any more details beyond what is listed in that bulletin, and can't answer any questions related to this, unfortunately.)
Contrast:
"Meanwhile, we suggest using the stronger security and isolation properties of EC2 instances to separate any untrusted workloads."
with:
"Google Compute Engine employs host isolation features which ensure that an individual core is never concurrently shared between distinct virtual machines. This isolation also ensures that, in the case that different virtual machines are scheduled sequentially, the L1 data cache is completely flushed to ensure that no vulnerable state remains."
The former does not inspire confidence. Given the hypervisor on EC2 is opaque to me, I'm not sure how I'm supposed to avoid co-tenanting in a risky fashion.
Re: Understanding L1 Terminal Fault aka Foreshadow: What You Need to Know
#30If helpful a few Cloud Providers Responses: Google Cloud - Google Cloud's protections against this new vulnerability: - https://cloud.google.com/blog/products/gcp/protecting-agains... ) - GCE Related information: - https://cloud.google.com/compute/docs/security-bulletins - GKE Related information: - https://cloud.google.com/kubernetes-engine/docs/security-bul... Oracle Cloud - https://blogs.oracle.com/oraclesecurity/…
Google writes that ‘Google Compute Engine employs host isolation features which ensure that an individual core is never concurrently shared between distinct virtual machines’.
However, GCE does offer shared core machine types (f1-micro and g1-small) with 0.2 and 0.5 vCPUs respectively. This seems to contradict their statement (unless the cores are not shared after all, but that doesn’t make sense from an economical standpoint).
Also, they offer machines with one vCPU, but since a vCPU is only a single hyper-thread and not a full core, this still allows for the core to be shared over multiple VMs. If this means that Google will stop using hyperthreading and instead give everyone a full CPU core per vCPU, that will likely give noticeable performance benefits (but cost more for them).