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

141–150 of 264 posts

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

#141

Post by CamperBob2 »

avian wrote: post #33
userbinator wrote: post #20

IMHO, with RowHammer, the hardware is broken and it will continue to be broken until users complain enough --- maybe to the point of absolutely refusing to buy --- that the manufacturers and designers stop thinking "works 99.9999999999% of the time" is good enough: https://news.ycombinator.com/item?id=12410274

Why would users refuse to buy hardware that works 99.9999999999% of the time when they apparently have no problem buying software that works 99% of the time? Radioactive decays and cosmic particles flipping bits give an upper bound for reliability. You are not going to see low-background packages and rad-hard chips in your iPhone.

Who cares if it works 99.9999999999999% of the time, if it fails 100% of the time someone deliberately exploits the bug?

This isn't a probability question. I don't understand why it's being discussed as if it were.

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

#142

Post by wasx »

nikanj wrote: post #120
bhouston wrote: post #99

Earlier quoted context omitted.

And the source of an older version of NT leaked a while back.

I think that was NT 4. I don’t think there’s much of that 20-year old code left in the kernel.

Actually given the horror stories that have been told about the windows source code over the years, I'd be very, very surprised if there wasn't 20 year old code in a lot of places.

Hell there's still 20 year old code running in the Linux kernel

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

#143

Post by ajarmst »

pkaye wrote: post #126
blattimwind wrote: post #109

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.

Alpha particle emissions are common causes of single-bit errors, especially from ceramic enclosure materials in integrated circuits. Mitigating soft errors from circuit packaging is an active area of research in materials science. Parity bits and CRC error checking are needed precisely to reduce the impact of these errors down to manageable levels.

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

#144

Post by saas_co_de »

daenney wrote: post #139
saas_co_de wrote: post #100

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.

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

> Capacity planning and forecasting is complicated

AWS and GCE certainly don't make it easier. 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.

> I severly doubt that [bare metal is more secure]

I am saying that shared hosting is fundamentally insecure. No matter what else you do, 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.

> cloud isn't competing with just providing you compute

I agree on this. But not all of those services work as well as advertised either.

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

#145

Post by mackal »

revelation wrote: post #51
jaccarmac wrote: post #49

The kernels for Gentoo have been all over the place for the past few weeks. I'm running 4.12 at the moment, then the repos updated to 4.14, which wouldn't build for me, so I waited a week for genkernel to modernize. When I came back 4.14 had been marked unstable and 4.12 was masked, making 4.9 the latest supported kernel. Seems that whatever is happening is a Big Deal.

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 flag is only enabled by default on hardened gentoo profiles. Non-hardened profiles has it disabled.

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

#146

Post by lolc »

hathawsh wrote: post #106
dmm wrote: post #53

Earlier quoted context omitted.

ECC doesn't protect you from from all rowhammer problems because they can flip more than two bits at a time, the limit which ECC can detect. "Tests show that simple ECC solutions, providing single-error correction and double-error detection (SECDED) capabilities, are not able to correct or detect all observed disturbance errors because some of them include more than two flipped bits per memory word" https://en.wikipe…

OTOH, a rowhammer attack on ECC memory will likely flip 1 bit before it flips 2, making attacks theoretically detectable. Without ECC, there's no clear way to detect an attack.

I'd assume that parity is checked on access, which may give enough time to flip more than one bit before it's detected.

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

#147

Post by lionradio »

brazzledazzle wrote: post #127
saas_co_de wrote: post #122

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.

One might migrate some super important instances to bear metal or cloud hardware under full control. If this is an embargo against a bug that could make VMs on the same hardware attackable this should be public.

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

#148

Post by neerajsi »

syshum wrote: post #65
preordained wrote: post #34

Earlier quoted context omitted.

If you're taking off for vacation and forgot to lock your door, the best thing would be to go back and lock it. If you couldn't get the door locked right away for some reason, you probably wouldn't want the news of your unlocked door broadcast through your neighborhood... Obscurity actually is a layer of security. The mistake is is when people are dependent upon it.

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.

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

#149

Post by [deleted] »

brazzledazzle wrote: post #127
saas_co_de wrote: post #122

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.

[deleted]
Post reply on HN