21–30 of 337 posts
What are they saying here?
Sorry for being naive. Are these kind of CPU Securities vulnerabilities new? Why it is in the past 20 years we have had close to zero in the news ( At least I wasn't aware of any ) and ever since Spectre and Meltdown we have something new like every few months. And as far as I am aware they are mostly Intel CPU only. Why? And Why not AMD? Something in the Intel design process went wrong? And yet all the Cloud Vendor…
I think it is definitely worth introspecting about the history. It has been known for over 20 years that sharing pretty much anything creates side channels but nobody knew how to reliably exploit them and it was assumed that side channels might never be exploitable. In recent years there has been massive progress in practical data extraction using side channels.
At what point do we simply revert to using typewriters for authoring sensitive documents, and pneumatic tubes (couriers for WAN) for networking? https://www.theguardian.com/world/2014/jul/15/germany-typewr...
But assuming a typewriter has no attack vectors is just as foolish as insecure networks IMO.
https://arstechnica.com/information-technology/2015/10/how-s...
Also: detecting text through keystrokes previously discussed here https://news.ycombinator.com/item?id=7448976 (https://people.eecs.berkeley.edu/~tygar/papers/Keyboard_Acou...)
Heck while I can't find a quick source, I remember a story about how the CIA designs rooms/walls and buildings to prevent sound from predictably bouncing through rooms in ways that could be captured from afar.
Spooks are usually 10 steps ahead of the public common sense this sense.
These CPU flaws make it seem as if virtualization in the data center is becoming really, really dangerous. If these exploits continue to appear, the only way forward would be dedicated machines for each application of each customer. Essentially, this might be killing the cloud by 1000 papercuts because it loses efficiency and cost effectiveness and locally hosted hardware does not necessarily have to have all mitigat…
I don't think you don't need to go this far. You can probably get away with circuit switching small blocks of hardware, and fully resetting them between handovers. Although you'd have to ensure sufficient randomisation / granularity to destroy side channels in the switching logic.
These CPU flaws make it seem as if virtualization in the data center is becoming really, really dangerous. If these exploits continue to appear, the only way forward would be dedicated machines for each application of each customer. Essentially, this might be killing the cloud by 1000 papercuts because it loses efficiency and cost effectiveness and locally hosted hardware does not necessarily have to have all mitigat…
At what point do we simply revert to using typewriters for authoring sensitive documents, and pneumatic tubes (couriers for WAN) for networking? https://www.theguardian.com/world/2014/jul/15/germany-typewr...
Long ago? https://www.theguardian.com/world/2013/jul/11/russia-reverts... (also https://www.cia.gov/library/readingroom/document/cia-rdp78-0... ) But assuming a typewriter has no attack vectors is just as foolish as insecure networks IMO. https://arstechnica.com/information-technology/2015/10/how-s... Also: detecting text through keystrokes previously discussed here https://news.ycombinator.com/item?id=7448976 ( http…
At what point do we simply revert to using typewriters for authoring sensitive documents, and pneumatic tubes (couriers for WAN) for networking? https://www.theguardian.com/world/2014/jul/15/germany-typewr...
We don't need to revert to typewriters. We just need computers designed with a real security model in mind, instead of piles of ah-hoc mitigations. However, I bet no one will invest in it until one of these exploits bring down AWS, take over Google's crawlers or something else of that sort.
https://www.dovermicrosystems.com/
Academics keep coming up with stuff for timing channels like partitioning, masking, and randomizing components. Personally, if not physical separation, I'd just do SMP with secret parts on different CPU that untrusted parts. Both memory safe on a separation kernel to isolate them. One design used different DIMM's, too.
These CPU flaws make it seem as if virtualization in the data center is becoming really, really dangerous. If these exploits continue to appear, the only way forward would be dedicated machines for each application of each customer. Essentially, this might be killing the cloud by 1000 papercuts because it loses efficiency and cost effectiveness and locally hosted hardware does not necessarily have to have all mitigat…
Looks like AMD Cpus are safe again.
Note that Spectre definitely affected AMD chips and in general these sorts of side channel attacks based on speculative execution are extremely likely to be effective against any chip (including AMD manufactured ones) that employ speculative execution though the precise implementation might have to be jiggered a bit.
Spectre, on the other hand, is harder both to fix in hardware and to attack because the victim context is itself tricked into speculatively executing code using attacker-supplied data that leaks information - it uses inherent properties of speculative execution rather than any kind of hardware bug, but it's only exploitable if there's some victim code that does exactly the right kind of processing on attacker-supplied data.