131–140 of 264 posts
Earlier quoted context omitted.
But this isn't one persons' door that's unlocked. This is more like a company that shipped a faulty door lock and is trying to keep it secret until they can ship fixed doors to everybody.
But wouldn't you want to know if your door is faulty, so you can either replace your door, delay your vacation until the new door arrives, or beef up your security system?
Earlier quoted context omitted.
Depends on the exploit, but all exploits can be mitigated by stopping your use of the exploited product. That is what companies don't want to happen so they would prefer to sacrifice their users' security and wait until they have a fix before the exploit is disclosed.
In this specific scenario what's the mitigation for cloud customers? Or even cloud providers? A customer can't migrate all of their infrastructure before a packaged exploit can be distributed. A provider can't dedicate hardware for every single customer. Let's be realistic here.
Not everyone is all in on cloud infrastructure. What about people who are right now deciding whether or not to move critical data to the cloud? Should their security be compromised by hiding the truth about a known exploit in order to "protect" people less concerned about security who already put their data at risk?
Earlier quoted context omitted.
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?
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.
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.
I'm confused about the TLB impact. The pythonsweetness link claims these patches now require TLB flushes when crossing the kernel/user boundary, but the description of KAISER @ lwn[1] suggests that these flushes are unnecessary with "more recent" processors supporting PCIDs. How recent is "more recent", and is the PCID support likely to be ported back to earlier kernels along with KPTI? TLB flushes for syscalls would…
If the problem is row-hammer style attacks on the TLB that let you map userspace writable pages into the kernel address space then any kernel entries remaining in the TLB when userspace is running are going to be a security hole. The problem won’t be a process writing to the kernel entry (that would be forbidden by existing code / hardware) but a process updating it’s own TLB entries in ways that corrupt adjacent ker…
Earlier quoted context omitted.
Radioactive decays and cosmic particles flipping bits give an upper bound for reliability well below 99.9999999999% If it works 99.9999999999%, then it has a failure rate of 0.0000000001%, or 1E-12. Considering that a modern CPU executes approximately 1E9 operations per second, and that regular HDDs have a worse-case BER of 1 in 1E14 bits, 1E-12 is actually rather horrible and the actual error rate of computer hardwa…
I edited my reply to remove the actual number. The argument still stands that you cannot expect 100% reliability.
Amazon is hosting life-safety applications in EC2. Commodity x86 hardware is grossly negligent for that environment.
Earlier quoted context omitted.
If the problem is row-hammer style attacks on the TLB that let you map userspace writable pages into the kernel address space then any kernel entries remaining in the TLB when userspace is running are going to be a security hole. The problem won’t be a process writing to the kernel entry (that would be forbidden by existing code / hardware) but a process updating it’s own TLB entries in ways that corrupt adjacent ker…
I don't think rowhammer style attacks are possible on TLBs, since they are SRAMs (CAMs, to be precise), not DRAMs.
Earlier quoted context omitted.
There are many examples of hardware using unreliable underlying layers, countered with whitening/scrambling, redudancy and other data encoding tricks. What would make RowHammer imprevious to these?
Those tricks cost latency. You can get away with hiding some of that latency in access time to persistent storage. It's much harder to do so with RAM. ECC helps, and can be done at full rate, but isn't a complete solution for all possible problems. And anything you do in hardware at full RAM speed is expensive.
The bare metal cloud providers will be rubbing their hands together
I never understand why people don't go bare metal. It is just as easy to automate, just as cheap (or cheaper) if you plan well, and more secure. A decade ago everyone knew that shared hosting was for hobby sites and stuff that didn't really matter. Maybe some more people will learn that lesson.
> It is just as easy to automate [..]
It's really not. As someone who's done provisioning automation at 2 companies, this is hard. Hardware is difficult, every new generation of hardware introduces new challenges in the provisioning and the more hardware configurations you need to support (and different vendors, all kinds of PCI plug-in cards etc), the more likely things go wrong. It takes a full team to build, maintain and debug this. It takes a couple of hours to build a GUI that calls the GCP API's to provision an instance for you, assuming you even need to do this instead of just using the Cloud Console directly. Sure, you pay for it, but now you have 4-10 engineers freed up to do something that provides actual value to your business.
> [..] if you plan well [..]
If. But that's really hard. Capacity planning and forecasting is complicated and the smaller a player you are, the harder it'll be for you to get a decent vendor contract with significant discounts and to be able to adjust and get to hardware quickly outside of your regularly forecasted buy-cycle. On the other hand, it's not your issue in the cloud. You request the resources and as long as you have the quotas, you'll get it (with rare exception).
> [..] and more secure [..]
I severly doubt that. In most cases, though you can host your stuff in certified DC's you'll still be in a colocation facility. Most cloud providers have their own buildings or rent complete buildings at a time. No one else but them has access to those grounds. Aside from that, take a look at what Google for example does on GCP to ensure that their code and only their code can boot systems, how they control, sign and verify every step of the boot process[0]. I've yet to see anyone do that and I doubt most companies that do bare metal have even thought of this or have the knowledge to even execute on this.
[0]: https://cloudplatform.googleblog.com/2017/08/Titan-in-depth-...
Aside from all of this, cloud isn't competing with just providing you compute. VM's (GCE, EC2) is just the onboarding ramp. The value is in all the other managed services they offer that you no longer need to build, maintain, scale and debug (global storage and caching primitives, really clever shit like Spanner or Amazon RDS/Aurora, massively scalable pub/sub and load balancing tiers, autoscaling, the ability to spawn your whole infrastructure or your service on a new continent to serve local customers in a matter of minutes etc). If all you're using cloud providers for is as a compute provisioning layer, then you're doing it wrong.
Earlier quoted context omitted.
It is being backported to 4.14, and presumably earlier kernel too.
Sure, with the appropriate baking time. But I don't see a cloud company taking an intermediate version of this patchset, backporting it themselves and then sending it out to all their customers in a hurry.