Live data from Hacker News

The mysterious case of the Linux Page Table Isolation patches

pythonsweetness.tumblr.com

101–110 of 264 posts

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

#101

AWS had scheduled maintenance requiring reboot of all EC2 instances in December. Maybe this is somehow related.

I think it was just their paravirtual instances that have a scheduled reboot. I haven't heard that any of the newer HVM ones are affected.

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

#102
post #14
post #5

Shouldn't cloud-grade computers be immune to rowhammer (or at least rowhammer should be much less efficient) as they typically use ECC RAM. Switching ECC RAM in a way that also modifies checksum in a deterministic way is (was?) not practical?

The bit flip would be done in a normal fashion - i.e. a command issued that changed the memory location, and hence updates the checksum. The occasional (about one bit flip per Terabyte per hour I think, on average) stray cosmic ray inducing a momentary over-voltage causing the checksum to now disagree would hopefully be within the design's ability to flip back.

That's not how rowhammer works.

It's a hardware level thing. Essentially, when you start rapidly flipping a single bit, that starts to 'leak' some current to the adjacent physical bits. This then allows you to flip a single bit. Especially if you can control bits on both sides of your target.

It's like you are using the bits you can control to 'simulate' an actual stray cosmic ray.

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

#103

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

Aren't there now hardware fixes for this in current generation ram?

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

#104

Earlier quoted context omitted.

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

Exactly. This is just some random nerd. There are people all over the world whose full time job it is to track open source projects to develop exploits.

and when script kiddies get wind that there is something potentially disastrous in the open, it can be exploited 10 times harder, that's all I'm saying.

I understand (and agree) that the system admins/owners should also be able to mitigate through knowledge, but it's a dilemma that I think is better resolved by the other solution

(in this case it's apparently a complex issue, but history has shown that there are surprisingly easy to exploit bugs/issues (see heartbleed, shellshock (which was apparently very quickly exploited.))

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

#105
post #57

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.

Generally speaking, a piece of JavaScript in some 0x0 pixel iframe in a tab you're not even looking at can't summon cosmic particles to manipulate your computer's main memory. Rowhammer can.

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

#106
post #53
post #5

Shouldn't cloud-grade computers be immune to rowhammer (or at least rowhammer should be much less efficient) as they typically use ECC RAM. Switching ECC RAM in a way that also modifies checksum in a deterministic way is (was?) not practical?

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.

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

#107
post #58

Earlier quoted context omitted.

Or indeed any bits of ECC. The fact that Intel omits or disables it on most CPUs is shameful.

There's ECC inside the chips.

The internal caches have ECC but rowhammer targets the DIMMs. ECC DIMMs would solve the issue but Intel, for market segmentation reasons, fuses off the ability to handle ECC memory in consumer chips.

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

#108
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!"

They weren't really trying to uncover the exploit such that they can reproduce it. They were trying to learn who the exploit affects and what the impact is. I don't think there's anything wrong with that. If you're an AWS customer who depends on hypervisor isolation for critical security guarantees, it helps you to know that this is threatened and perhaps exploitable. Please don't buy into the idea that embargoes and…

Please don't buy into the idea that embargoes and coordinated disclosure are sacred. They tend to just reinforce existing power structures, sometimes in an unethical (or at least unfair) way.

They're an attempt to minimize harm, by getting things patched while minimizing information leaked to blackhats.

Just because giving preference to groups with a better reputation and more market share isn't "fair", doesn't mean it's automatically wrong. Now, if you can show that it actually doesn't help . . .

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

#109
post #64
post #33

Earlier quoted context omitted.

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.

Almost everything I've seen on error rates from radioactive decay and cosmic particles has been on servers in data centers. 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 ask because I had a couple of home desktop Linux boxes once, without ECC RAM, that were running as lightly loaded servers. I ran a background…

> 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 of magnitude to matter here. Probably not.

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

#110
post #84

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

Umm this is very shortsighted and absolutely trash. There are many types of users and some don't care if it fails in a blue moon. Hell 99% might be good enough if the price was right.

99% would basically be the region where the CPU itself can't power on any more because it is too unreliable to execute any kind of power-on sequence.
Post reply on HN