AWS had scheduled maintenance requiring reboot of all EC2 instances in December. Maybe this is somehow related.
The mysterious case of the Linux Page Table Isolation patches
101–110 of 264 posts
Re: The mysterious case of the Linux Page Table Isolation patches
#102Shouldn'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.
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
#103IMHO, 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
Re: The mysterious case of the Linux Page Table Isolation patches
#104Earlier 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.
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
#105Earlier 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.
Re: The mysterious case of the Linux Page Table Isolation patches
#106Shouldn'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…
Re: The mysterious case of the Linux Page Table Isolation patches
#107Earlier 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.
Re: The mysterious case of the Linux Page Table Isolation patches
#108"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…
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
#109Earlier 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 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
#110IMHO, 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.