121–130 of 337 posts
Earlier quoted context omitted.
Security by obscurity is no security
This saying rubs me the wrong way, because confidentiality is 1/3 of security. Obscurity is critical or this wouldn't be a vulnerability.
You can have unintentional exploits/vulnerabilities in free/open source software or hardware too.
Earlier quoted context omitted.
You can kiss any semblance of reasonable performance goodbye if you eliminate "speculative execution". Pipelining is the most basic tool in the toolbox. Even microcontrollers do it.
Pipelining isn't strictly the same thing as speculation, though, is it? If I have, add %rax, %rbx add %rcx, %rdx I can pipeline those without needing to speculate on anything. If there is a dependency on a previous instruction, then we might have to speculate, but hopefully there is still some case for pipelining? Have any of these bugs been completely based on speculation, or is it always speculating across privileg…
Intel does more speculation, but you won't find anything beyond the tiniest embedded CPUs which don't do any.
Do cloud providers commonly float cores between VMs? I could see instances like the AWS T family (burstable) sharing, but I had always assumed that most instance types don't over-provision CPU. If that's the case, my CPUs are likely pinned to my VM. I could still have evil userland apps spying on my own VM, but I would not expect this to allow other VMs to spy on mine.
Earlier quoted context omitted.
> AMD are not better. They’re probably worse. This argument makes zero sense and fails real world inspection. You see, researchers did publish the fact that it affected AMD on Spectre. For this vulnerability, they were unable to reproduce the bug on AMD (their words). Which means that they tried.
Intel and AMD don't have to share the same bugs for AMD to be worse. Consider you've got two sets of vulnerabilities: [1, 2, 3] and [2, 4, 5, 6, 7, 8]. If I label set 1 Intel, and set 2 AMD, then you can see how doing your research on Intel first will make it seem like Intel has 3x the vulnerabilities as AMD - even though it actually has half.
So at what point do we start producing CPUs specifically aimed at running a kernel/userland? Why don't we have a CPU architecture where a master core is dedicated to running the kernel and a bunch of other cores run userland programs? I am genuinely curious. I understand that x86 is now the dominant platform in cloud computing. But it's not like virtualization needs to be infinitely nested, right? Why not have the ho…
You cannot give each VM their own core. The business model of the cloud is that multiple VMs with virtual cores run on a single real core.
Businesses move to the cloud for lower TCO compared to solutions they would have to hire entire teams of engineers to deploy and manage.
Something like AWS, the CPU cores account for a small percentage of the revenues they make.
The vast majority of their EC2 instance types have dedicated CPU cores. This may not necessarily mean that VMs are pinned to cores, but just that the overall compute power available is pretty tightly segmented.
But regardless, as a technical decision maker, I’ll move my organization to the cloud because of scalability, fault-tolerance, reliability & security - things that would be impossible or prohibitively expensive to do on-prem. CPU cores are rounding errors in comparison.
Earlier quoted context omitted.
The focus is on Intel partially because it's the most valuable target, so we might be looking at selection bias.
That's really not the case. Once you know of an attack of this sort it's pretty easy to test everyone's chips for it. Bascially every Intel chip since Nehalem is vulnerable to Meltdown, as are IBM's POWER chips, as is one out-of-order ARM core but not any of the others. And we know that AMD chips are safe from that vulnerability. Whether you run security checks in sequence or in parallel with a data access is pretty…
Earlier quoted context omitted.
Security by obscurity is no security
This saying rubs me the wrong way, because confidentiality is 1/3 of security. Obscurity is critical or this wouldn't be a vulnerability.
All “secrets” are eventually revealed, security is about managing the risks and timing associated with this revelations
So at what point do we start producing CPUs specifically aimed at running a kernel/userland? Why don't we have a CPU architecture where a master core is dedicated to running the kernel and a bunch of other cores run userland programs? I am genuinely curious. I understand that x86 is now the dominant platform in cloud computing. But it's not like virtualization needs to be infinitely nested, right? Why not have the ho…
Earlier quoted context omitted.
The stream of critical CPU vulnerabilities starting with Spectre/Meltdown last year are related to speculative execution , not just Intel. (AMD and ARM CPUs are also vulnerable to Spectre, for example.) Intel CPUs are sometimes vulnerable to additional attacks because they speculate in more scenarios than other designs. But fundamentally, as long as multiple different trust domains are sharing one CPU that speculates…
> Spectre/Meltdown, which leak the speculative information via the cache side-channel, completely blindsided the architecture community; it wasn't just one incompetent company. In the x86 space, Meltdown absolutely was down to one company apparently deciding to over-optimize for performance. I can't find it now, but I remember reading a thread from (I think) the OpenBSD devs about how the Intel MMU documentation desc…
Serious weasel wording, outside of x86 space every other high end architecture also had Meltdown issues, ARM, and IBM's POWER and mainframe designs.
What is the recommended course of action? Stop buying Intel products, and devices which contain them? What about devices with older processors? I'm still running a Sandy Bridge rig and it works fine, except for the side channel vulnerablities. It's probably not going to be patched. I also have a cheaper computer with a Skylake processor, which is newer yet still vulnerable! It's only a matter of time until something…