Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The mysterious case of the Linux Page Table Isolation patches

pythonsweetness.tumblr.com

Post reply on HN
Print view View original

151–160 of 264 posts

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

#151

Post by justincormack »

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 result in a page fault.

Disable page table isolation by default on AMD processors by not setting the X86_BUG_CPU_INSECURE feature, which controls whether X86_FEATURE_PTI is set.

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

#152

Post by foobarbazetc »

saas_co_de wrote: post #100
qume wrote: post #44

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.

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 bare metal hosts unless you’re doing a lot of egress.

The calculus changes when you realize that you’re over-provisioned on the bare metal side for a variety of reasons: high availability, “what if”, future growth that’s more medium term than short, etc.

Then you scale back the numbers you’re plugging into the calculator and things are still expensive but now within reason.

Couple that with things like global anycast region aware load balancer, firewalls (an in-line 10GigE highly available firewall costs a lot of money), ability to spin up hundreds of cores in 5 seconds and the value proposition becomes clearer.

It still depends on your work load, but there’s a lot more to consider than just straight up monthly cost.

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

#153

Post by moyix »

sciurus wrote: post #92
gjvc wrote: post #23

Earlier quoted context omitted.

Where is the paper and public demonstration in this case?

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

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

#154

Post by cookiecaper »

fasterblade wrote: post #76
revelation wrote: post #51

Earlier quoted context omitted.

Thats because Gentoo decided to switch on a new compile flag, then didn't bother to test that the kernel still boots: https://lkml.org/lkml/2017/12/29/449

The same compiler (mis-)feature was also the cause of spurious crashes in Go applications (diagnosed about a month ago: https://marcan.st/2017/12/debugging-an-evil-go-runtime-bug/ ). Linus's comment is fun: So yes, It's a terminally broken compiler from hell. I assume gentoo has applied some completely broken security patch to their compiler, turning said compiler into complete garbage.

Linus clarified later that he could reproduce on Fedora with the relevant build flag (-fstack-check). His initial assumption that this was caused by an out-of-tree patch specific to Gentoo was incorrect.

The patch to "fix" it is explicitly disabling -fstack-check for the kernel build. I believe that will go out in 4.14.11 (it is not in 4.14.10).

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

#155

Post by pixl97 »

neerajsi wrote: post #148
syshum wrote: post #65

Earlier quoted context omitted.

Your analogy is severely flawed as my door lock is under my control and I know about the risks (i.e it is unlocked) so I can take the steps I need to mitigate that risk For your analogy to apply here it would be the manufacturer of the door lock having a master key stolen then not telling anyone about it until they have a new lock for you to buy from them, in the case of a lock I would want to know that the lock is u…

Locksmiths can get into many locks that people use to secure their houses. That doesn't mean that I want them to share that knowledge widely.

Eh, that information is shared widely. Some decent googl-fu will get you the information you want.

The difference is a lock-pick can't exploit 20,000 doors in 20 minutes.

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

#157

Post by cookiecaper »

justincormack wrote: post #28
revelation wrote: post #22

Earlier quoted context omitted.

Well Intel for one manufactures the insecure CPUs.. This will be merged for 4.16, when there is no 4.15 release yet. No idea what your cloud computing companies run but it's not 4.15-dirty, and backporting this monster is a great recipe for a nightly emergency when it goes OOPS. edit: it isn't even merged yet.

It is being backported to 4.14, and presumably earlier kernel too.

Yep. The kernel maintainers are being so aggressive with this that I'll be very concerned if there isn't a major security issue coming down the pipe. I know that Linux is considered fast and loose in various circles of old-school hackers, and granted, but merging this type of fundamental change into stable is not normal. There's something brewing here that is pushing this to completion.

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

#158

Post by acoye »

justincormack wrote: post #151

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…

Do you think this could be within the rather new Intel AVX 512 ISA or older intel CPUs like Sandy Bridge (first AVX chip) could also suffer?

- edit - I checked Ryzen ISA, they support AVX2. So probably AVX512 is the issue.

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

#159

Post by caf »

tbrownaw wrote: post #2

"Hey, I think I noticed a horrible horrible embargoed security bug. I know, I should do my best to pole holes in the embargo early!"

Anyone capable of exploiting this issue based on the information in that blog post, already knew everything in that blog post.

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

#160

Post by syshum »

neerajsi wrote: post #148
syshum wrote: post #65

Earlier quoted context omitted.

Your analogy is severely flawed as my door lock is under my control and I know about the risks (i.e it is unlocked) so I can take the steps I need to mitigate that risk For your analogy to apply here it would be the manufacturer of the door lock having a master key stolen then not telling anyone about it until they have a new lock for you to buy from them, in the case of a lock I would want to know that the lock is u…

Locksmiths can get into many locks that people use to secure their houses. That doesn't mean that I want them to share that knowledge widely.

I see so now we are advocating for the suppression of Speech... Because how else are you going to prevent that? Pretty sure there are 100's of youtube vidoes on lock picking, you want to ban all of them?
Post reply on HN