231–240 of 264 posts
Earlier quoted context omitted.
Or indeed any bits of ECC. The fact that Intel omits or disables it on most CPUs is shameful.
one bit of ECC isn't sufficient...
Earlier quoted context omitted.
>Intel CPU do some speculative execution on priviledged data from unpriviledged code, including from (at least some and at least part of) separate following instructions. That was known since pentium 3 times, I wonder why nobody thought of this as a wonderful exploit target before >I'm 90% convinced there is no way Intel managed to close all the side-channels on such a complex architecture This is why one should not…
tricky grammar. You mean formal, mathematical verification instead of simulation, I suppose, but I am not aware of any different method.
Ideally, a much closer to complete verification should be done in addition to simulation, like a mathematical proof that register content will never be like set A if inputs are set B
Earlier quoted context omitted.
Is there anywhere to read up on the bustedness of the stack probing feature? (apart from the obvious incompatibility with trying to do that for kernel code).
Probing more than a page size below the current stack pointer is wrong. Probing more than a page size further when one's saved frame area, save area, locals area, and (maximum) calling parameters area do not amount to a page in total is also wrong. For more on the considerations that underpin stack probing, see http://jdebp.eu./FGA/function-perilogues.html#StackProbes for starters.
If true, this is pretty huge. As if the AWS "You blew through your budget" emails right around midnight of New Years were only an appetizer. Edit: AWS Spurious Budget Email Barrage: https://www.reddit.com/r/aws/comments/7ndvli/anybody_get_spu...
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.
At every step along the way, there's been a choice of "Well, we could own the hardware and incur overhead costs, or we could trust someone else and pay our share of lower overhead. It'll mean giving up some control, but it'll save us a few bucks."
Or maybe it goes like "Well, we could develop with practices that result in more robust code, but we'd be slower to market."
There's definitely a sidetrack of "If we crank up the clock too much, all sorts of things get wibbly and we can no longer guarantee that the outputs match the inputs, but we don't actually have ways of doing it correctly at these speeds. The press will slam us if we don't keep pace with Moore's law, how could we launch a product with only marginal speed gains?"
And pretty often I think it sounds like "The ops staff says they're overworked and we need to add people or we risk an incident, but Salesman Bob says we can actually fire most of them if we put our stuff in BobCloud."
At every step along the way, someone made a conscious choice to do the insecure thing. The folks with their eye on security were dismissed as naysayers, and profit was paramount. And because these practices became so common, they became enshrined in market norms and expected overhead costs.
> A provider can't dedicate hardware for every single customer.
A provider absolutely could dedicate hardware for every single customer, that's literally how every provider operated before virtualization. It just wasn't as profitable as virtualization.
The story of the Three Little Pigs was supposed to teach about the importance of robust infrastructure. Nobody should be surprised when the wolf shows up. And every pig had the choice to build with sticks or bricks, it would just take more work or cost more.
And I see your message as saying "Are you serious? Build with something other than straw?! But we already own so much straw! All the pigs have straw houses, won't someone think of the pigs?"
Meanwhile the bankrupt brick vendor's assets have been auctioned off, and the wolves are salivating.
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.
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?
One question I have around this is whether the patches made to the Windows kernel in November exhibit the same performance hits. Does anyone know? I'm due to refresh my gaming PC, and I was going to go with Intel again as they've not been a problem. However, if Intel chips are going to incur the same 5% - 50% performance hit on Windows, I might end up investing in AMD hardware instead.