Live data from Hacker News

The mysterious case of the Linux Page Table Isolation patches

pythonsweetness.tumblr.com

161–170 of 264 posts

Re: The mysterious case of the Linux Page Table Isolation patches

#161

Looks like it is speculative execution based, and does not affect AMD https://lkml.org/lkml/2017/12/27/2 AMD processors are not subject to the types of attacks that the kernel page table isolation feature protects against. The AMD microarchitecture does not allow memory references, including speculative references, that access higher privileged data when running in a lesser privileged mode when that access would resu…

I guess Intel decided to speculate data access regardless of privilege level of the target address, with the theory that what has been successfully speculated can't be accessed anyway before the permission are really checked, and somebody found a bug (or given all Intel processors are taggued as unsecure, maybe a quasi-architectural hole) that let read the speculated data or a significant subset or trace of it.

My wild guess is that you can read a good portion (if not all) of the memory (or a significant subset or trace of it) of the whole computer from unprivileged userspace programs.

Re: The mysterious case of the Linux Page Table Isolation patches

#162

Earlier quoted context omitted.

I have to disagree. If you look purely at hardware cost of bare metal vs. what the same compute costs on cloud then sure, cloud is more expensive. > 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…

> It takes a couple of hours to build a GUI that calls the GCP API's to provision an instance for you Yes, but you will hit all the same problems with different hardware generations, different configs with different limitations, etc. If anything GCE and AWS have more complex offerings than most bare metal hosts. And you have all the same maintenance issues as you run stuff over time and hardware and software updates…

> Yes, but you will hit all the same problems with different hardware generations, different configs with different limitations, etc. If anything GCE and AWS have more complex offerings than most bare metal hosts.

I haven't hit any issues with hardware generations. At worst what I've had to do is blacklist a GCP zone b/c it misses an instance type I need. In most cases I don't need to care and images that can boot are provided and maintained by the respective cloud provider, so you can build on top of that. I don't need to source or test components together, or spend hours figuring out why this piece of hardware isn't working well with that one. Or why this storage is slower than the other disk with the same specs from a different vendor. I don't need to lift a finger or deal with any hardware diversity issues, I just do an HTTP POST and less than a minute later I have an GCE instance available to me. Though in most cases I don't even do that, I just instruct GKE to schedule containers for me. I also don't need to worry about any hardware renew cycles, deal with failing hardware, racking and expansion of my DCs and what not.

The reason GCP and AWS have more complex offerings is b/c they can afford to provide it. Due to their scale they can shoulder the complexity of letting you chose from a vast array of different hardware configurations, which usually also results in better utilisation for them. Most people can't, which is why bare metal host options are much more constrained. And as a consequence why a lot of resources are wasted b/c it's especially hard to find someone supporting small instance types for just bare metal.

> AWS and GCE certainly don't make it easier.

To me they do. I don't need to deal with the hardware. I don't need to plan buying cycles, account for production cycles and chip releases by manufacturers and factor in how that's going to affect supply, or how an earthquake in Taiwan will make it prohibitively expensive for me to get the disk type I normally want to. I still need to do capacity planning, but I can tolerate much bigger fluctuations in those, and people's usage patterns, in the cloud than I can on bare metal. Unless I want to have hundreds of machines sitting idle, just in case I might need them.

But the best thing is, if I get it wrong in the cloud, I can correct, in a matter of minutes if I want to. Too big instance types? OK, I'll spin up smaller ones, redeploy and tah-dah my bill goes down. Sure you could do that on bare metal, assuming you can even get to a right/small enough instance type, but it's far from this easy in most cases.

> And if you can't capacity plan accurately on cloud and take advantage of spot pricing and auto-scaling then you will be paying 10X price, which describes most smaller players.

But then we're back down to trying to use the cloud just for compute, which is not what you should be doing and not where the value of a cloud offering comes from.

> I am saying that shared hosting is fundamentally insecure.

Though that's definetly true security isn't black or white, it's not secure vs. insecure. Something that you might consider an unacceptable risk (theoretical or practical) might be entirely fine for someone else. There are definetly cases in which this would be of major concern, but for most people it really isn't. Aside from that, as both hardware designs are changing and software mitigations are deployed we're able to achieve stronger and stronger isolation. Eventually, for all intents and purposes, this will be solved.

> if you let untrusted people run code on the same server that is a huge risk that assumes many, many layers of hardware and software are bug free.

This sitll holds true even if you only let your people run code on the same instance (unless you're also only running a single process/app per server?). It becomes a bit more problematic but there's also a lot more research in this area going on than a few years back. We're discovering issues, sure, but we're also getting better and better at mitigating them.

> But not all of those services work as well as advertised either.

True. Every cloud provider could do better. But then, I'd like to see anyone attempt and succeed at what AWS, Google and Microsoft (or smaller shops like Digital Ocean, Rackspace) etc are doing, at their scale and with a staggeringly diverse portfolio of services and high SLAs. All taken care of for you, so you can actually assemble their primitives into useful things for your business, instead of needing to spend months and multiple teams to build the building blocks in the first place (and then also the cost of continued development and maintenance of these capabilities, and of course adding more and more of these capabilities yourself as your organisation's needs evolve).

Re: The mysterious case of the Linux Page Table Isolation patches

#163
post #25

Earlier quoted context omitted.

The patchset being developed in the open, and the rationale for the development being done in the way it is, are two very different things.

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?

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...

Re: The mysterious case of the Linux Page Table Isolation patches

#164
post #39

Earlier quoted context omitted.

No, but they prevent everybody with ill-intent from exploiting the issue en-masse

If this guy can figure this out, anybody with the means and motivation to write such an exploit is already working on t.

All of the serious hackers with resources have a paid mole involved in the embargo discussion mailing list. The most dangerous people already know.

Embargo is simply a way to make sure the huge, rich cloud providers don't have their reputation tarnished at the expense of everyone else. "Stay with bigco, we fix things before everyone finds about it"

Re: The mysterious case of the Linux Page Table Isolation patches

#165
post #153
post #92

Earlier quoted context omitted.

https://gruss.cc/files/kaiser.pdf

As the article says, rushing through a change this large with a performance penalty just to fix KASLR is very unlikely. KASLR is a fairly weak protection that has been broken many times (particularly on Windows – and yet Windows is still rolling out a similar patch).

Its even worse than that. KASLR is only a mitigation, not an architectural protection (and "breaking KASLR" does not gives you an exploit by itself, you have to find another bug), so there is absolutely no way Linus would consider that just fixing KALSR command the (somehow rushed) inclusion of this patch, moreover enabled by default...

Re: The mysterious case of the Linux Page Table Isolation patches

#166

Earlier quoted context omitted.

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.

As someone who shares your skepticism of the cloud, I can say that people don’t switch from bare metal hosting (something like SoftLayer) to AWS/GCP for the cost. If you do the math like “we have 1000 cores and 2048Gb of RAM and 10Tb of RAID’ed SSD” and then plug that in to the GCP calculator... it’s going to be at minimum 1.5-2x your bare metal cost. That’s not even including bandwidth which is pretty much free at b…

Totally agree. Cloud makes tons of sense if your workload is really dynamic. Lots of small players are running static workloads though because actually setting up dynamic workloads is pretty complex.

I use GCE for DNS, Storage, CDN (for fronting storage backed files), dynamic workloads that can run on preemptible instances, and scalable instances to serve published static content, but I use dedicated servers for databases, elasticsearch, redis, and application servers fronting those things.

Re: The mysterious case of the Linux Page Table Isolation patches

#167

Looks like it is speculative execution based, and does not affect AMD https://lkml.org/lkml/2017/12/27/2 AMD processors are not subject to the types of attacks that the kernel page table isolation feature protects against. The AMD microarchitecture does not allow memory references, including speculative references, that access higher privileged data when running in a lesser privileged mode when that access would resu…

maybe it has to do with CR3 register? https://patchwork.kernel.org/patch/10138835/

Edit: switched to link without AD cancer

Re: The mysterious case of the Linux Page Table Isolation patches

#168

Looks like it is speculative execution based, and does not affect AMD https://lkml.org/lkml/2017/12/27/2 AMD processors are not subject to the types of attacks that the kernel page table isolation feature protects against. The AMD microarchitecture does not allow memory references, including speculative references, that access higher privileged data when running in a lesser privileged mode when that access would resu…

They might have succeeded to make it work: https://cyber.wtf/2017/07/28/negative-result-reading-kernel-...

Re: The mysterious case of the Linux Page Table Isolation patches

#169
post #116
post #88

Non-AMP link: http://pythonsweetness.tumblr.com/post/169166980422/the-myst...

Alternatively, use Firefox (on your mobile) to skip Amp and other sillinesses. Greatly improved my mobile browsing experience, haven't looked back (ublock origin, hint hint).

Firefox is pretty slow on my phone and sometimes when I try to search something, nothing happens. I want to like it, but chrome is just a lot smoother :'(

I do love how Google tries to "downgrade" its experience on Firefox mobile, but all it really does is cut out all the javascript and material design bullshit.

Re: The mysterious case of the Linux Page Table Isolation patches

#170
post #126

Earlier quoted context omitted.

> I wonder if home systems are equally vulnerable, or if there is something about data center system design or facilities that make them more susceptible? I was told once that today's concrete has a much higher background radiation than brick and mortar from before the 50s. There is also more steel in data centres. However, I'm not at all sure if background radiation of building materials is even in the right order o…

I think you need high energy radiation like cosmic rays from space to create problems. So those at higher elevation are at more risk. Heavy material like concrete may block this radiation.

Concrete and brick are significant sources of radiation. Especially when new.

I don't know if the sort of radiation they give out is of much risk to computers however.

Post reply on HN