71–80 of 264 posts
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
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?
"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…
The bare metal cloud providers will be rubbing their hands together
Earlier quoted context omitted.
Embargos do not make you secure. If the bug exists the only safe assumption is that it is already being exploited. The faster the information gets out the better.
No, but they prevent everybody with ill-intent from exploiting the issue en-masse
Prior to disclosure there will always be the possibility that some users are being exploited without their knowledge.
Therefore disclosure always improves the situation by giving those who could have been exploited without their knowledge the choice to take mitigation steps.
All of the "responsible disclosure" nonsense is just PR by companies who want to avoid the most obvious mitigation, which is for customers to stop using their products.
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
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.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
The current miniaturization of DRAM circuitry doesn't really allow for a hardware fix for the RowHammer attack. During DRAM manufacturing a test similar to the RowHammer attack exists. This test has certain bounds for passing. If the bounds were tightened up to the level of perfection to prevent the attack it would drop the yield a considerable amount.
Earlier quoted context omitted.
Embargos do not make you secure. If the bug exists the only safe assumption is that it is already being exploited. The faster the information gets out the better.
No, but they prevent everybody with ill-intent from exploiting the issue en-masse
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?
Earlier quoted context omitted.
The current miniaturization of DRAM circuitry doesn't really allow for a hardware fix for the RowHammer attack. During DRAM manufacturing a test similar to the RowHammer attack exists. This test has certain bounds for passing. If the bounds were tightened up to the level of perfection to prevent the attack it would drop the yield a considerable amount.
There are many examples of hardware using unreliable underlying layers, countered with whitening/scrambling, redudancy and other data encoding tricks. What would make RowHammer imprevious to these?
ECC helps, and can be done at full rate, but isn't a complete solution for all possible problems. And anything you do in hardware at full RAM speed is expensive.