Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

ZombieLoad: Cross Privilege-Boundary Data Leakage on Intel CPUs

cyberus-technology.de

Post reply on HN
Print view View original

261–270 of 337 posts

Re: ZombieLoad: Cross Privilege-Boundary Data Leakage on Intel CPUs

#261

Post by dfrage »

zelon88 wrote: post #250

So far there seem to be far more of these vulnerabilities in Intel CPUs. Is that a reflection of engineering differences or a statistical byproduct of the market share of Intel CPUs? I run AMD not because of the security implications but because I feel every dollar that goes to Intel competition will push Intel and thus the entire industry forward.

Market share is a good answer, in x86 space alone per https://www.extremetech.com/computing/291032-amd-gains-marke... which I found without putting much effort into it, AMD's share in servers is negligible and even dropped in the last quarter. On the other hand mobile and especially desktop are rising smartly, but still somewhat modest. IoT is excluded, and AMD could be doing well there to the extent anyone's using x86 for that, and there's also (quasi) embedded like network gear.

So the cloud vendors are 97% minimum Intel, they're exquisitely vulnerable both technically and reputationally to these bugs, the stakes are existential for them and they have a lot of money they can throw at the problem, whereas the users of notebooks and desktops are a much more diffuse interest.

As I've mentioned many times in these discussions today, everyone had Spectre issues, and everyone but AMD has Meltdown ones. The more recent vulnerabilities are Intel only because they're using what was learned from those first two to attack Intel specific features like the SGX enclave.

Re: ZombieLoad: Cross Privilege-Boundary Data Leakage on Intel CPUs

#262

Post by mgalgs »

echopom wrote: post #138
Fej wrote: post #76

What is the recommended course of action? Stop buying Intel products, and devices which contain them? What about devices with older processors? I'm still running a Sandy Bridge rig and it works fine, except for the side channel vulnerablities. It's probably not going to be patched. I also have a cheaper computer with a Skylake processor, which is newer yet still vulnerable! It's only a matter of time until something…

> What is the recommended course of action? Stop buying Intel products, and devices which contain them? There is absolutely nothing to be done on our level about this. I'm fairly convinced this is systemic issue that can only be solved by redesigning almost entirely modern cpus and computers architecture. I can draw a parallel to approximately all Intel cpus which are know to have a dedicated "mini cpu" called "Minix…

> Not only we need to redesign computers and cpu architecture but we desperately need to make that entire process and knowledge open source , available to all and more transparent.

Here's hoping OpenRISC takes off!

Re: ZombieLoad: Cross Privilege-Boundary Data Leakage on Intel CPUs

#263

Post by dethac »

strmpnk wrote: post #103
bin0 wrote: post #93

Earlier quoted context omitted.

From what I have heard, these flaws mostly affect Intel because they are the largest CPU manufacturer. They also dominate the datacenter and cloud-compute industries for now, which are by far the highest value targets. But as an Intel consumer, I am not happy. My understanding is that more stuff can be fixed in microcode, but I suppose a bug could show up which was not practically fixable. If that happened, I would c…

> these flaws mostly affect Intel because they are the largest CPU manufacturer It doesn't have anything do to with how large Intel is. They have clearly made a more aggressive hardware design which has more corner cases to break. The designs are broken and microcode can patch some variants of these side channels but the overhead is becoming a problem. In this case it's not certain if microcode can address the proble…

It's undeniable that they've made aggressive hardware decisions, but... Intel dwarves their second largest competitor (AMD) in revenue by an order of magnitude... and remember, AMD sells GPUs as well.

They are BY FAR the largest producer of CPUs for laptops, desktops, and servers. Note that on each of these platforms, arbitrary code execution is an issue.

Now for phones? Less so. Aggressively locked down software can help.

So, as a researcher, who are you going to research? AMD, who has negligible market share? Apple, who completely locks down their platform? Qualcomm? Well, that's an option, but Intel still makes them look small. Vulnerabilities in Intel CPUs affect the most people and the most money... You're naturally going to put more research into Intel.

It absolutely does have something to do with how large Intel is.

Re: ZombieLoad: Cross Privilege-Boundary Data Leakage on Intel CPUs

#264

Post by Uristqwerty »

cfallin wrote: post #88
Fej wrote: post #76

What is the recommended course of action? Stop buying Intel products, and devices which contain them? What about devices with older processors? I'm still running a Sandy Bridge rig and it works fine, except for the side channel vulnerablities. It's probably not going to be patched. I also have a cheaper computer with a Skylake processor, which is newer yet still vulnerable! It's only a matter of time until something…

The stream of critical CPU vulnerabilities starting with Spectre/Meltdown last year are related to speculative execution , not just Intel. (AMD and ARM CPUs are also vulnerable to Spectre, for example.) Intel CPUs are sometimes vulnerable to additional attacks because they speculate in more scenarios than other designs. But fundamentally, as long as multiple different trust domains are sharing one CPU that speculates…

Reading about speculative execution exploits makes me wonder whether it would be useful to have a speculation register, and an instruction prefix that claims one bit of that register, much as a mutex, while the prefixed instruction is being speculated about. Assuming a compiler intelligent enough to key a bounds check and later array access to the same speculation bit, or a language exposing low-level functionality to the programmer, Spectre could be defeated with minimal performance impact. Perhaps it could also be used to work around many other sorts of speculative execution flaws that might turn up in the future.

Re: ZombieLoad: Cross Privilege-Boundary Data Leakage on Intel CPUs

#265

Post by ct520 »

amluto wrote: post #193
cfallin wrote: post #148

Earlier quoted context omitted.

Yes, that's true, several of the vulnerabilities involve checks that are performed late (not at time of speculative access, but at some point before instruction commit). Not excusing the design choice at all, but it's conceivable that an engineer could make this choice if (i) side-channel effects of the speculation are not considered at all, and (ii) the postponement of the check allows the load latency to be reduced…

I’m not a CPU architect, but it seems like Intel saved a couple gates by putting garbage instead of zeroes in the pipeline.

Your not, but the gentlemen your replying to is. Bet you can’t guess where and what he worked on?

Re: ZombieLoad: Cross Privilege-Boundary Data Leakage on Intel CPUs

#266

Post by nullwasamistake »

fakwandi_priv wrote: post #114

Apparently Intel attempted to play down the issue by trying to award the researchers with the 40,000 dollar tier reward and a separate 80,000 dollar reward as a "gift" (which the researchers kindly denied) instead of the maximum 100,000 reward for finding a critical vulnerability. Intel was also planning to wait for at least another 6 months before bringing this to light if it wasn't for the researchers threatening t…

It's worse than that. Some of these flaws have been known for over a year already. Many vendors with implementation details of the fixes have said "full mitigation may require disabling hyperthreading".

Wtf does that mean exactly? Do the patches and microcode work or do they not? I expect the truth to come out as OSS maintainers come out of embargo and others analyze the patches. But it sure looks like VM's on your favorite cloud provider will still be vulnerable in some ways because they're not turning off HT.

Wired has many details of your Dutch link in English. https://www.wired.com/story/intel-mds-attack-speculative-exe...

Intel pressuring vendors to not recommend disabling hyper threading? Apple has added the option to MacOs, so presumably the mitigations are not completely effective: https://www.theregister.co.uk/2019/05/14/intel_hyper_threadi...

Re: ZombieLoad: Cross Privilege-Boundary Data Leakage on Intel CPUs

#267

Post by pjc50 »

guido_vongraum wrote: post #172
echopom wrote: post #138

Earlier quoted context omitted.

> What is the recommended course of action? Stop buying Intel products, and devices which contain them? There is absolutely nothing to be done on our level about this. I'm fairly convinced this is systemic issue that can only be solved by redesigning almost entirely modern cpus and computers architecture. I can draw a parallel to approximately all Intel cpus which are know to have a dedicated "mini cpu" called "Minix…

Me being a caveman who believes that technology is a hammer that still can be used to drive nails into building materials instead of our own heads, I'm longing for an Intermesh of simple networked 8-bit machines running on vanilla (no ARM core bonuses) FPGAs, with CPUs simple enough to be predictable and understood not by a select few superhumans in the world, but by a critical mass of people, and communication proto…

> Are there any massively parallel supercomputing tasks whose results couldn't be summarized and reduced to mere text, which is not too hard to move over the airgap manually?

Video decoding? Games? You know, the major use cases for custom highly patented hardware design?

Re: ZombieLoad: Cross Privilege-Boundary Data Leakage on Intel CPUs

#268

Post by cfallin »

ct520 wrote: post #265
amluto wrote: post #193

Earlier quoted context omitted.

I’m not a CPU architect, but it seems like Intel saved a couple gates by putting garbage instead of zeroes in the pipeline.

Your not, but the gentlemen your replying to is. Bet you can’t guess where and what he worked on?

Yup, I worked for a bit at Intel, but I don't speak for them, I wasn't involved in any of the designs under discussion, and everything I'm saying here is public knowledge in the computer architecture community. I figured that the perspective from the academic comparch world might be interesting.

Re: ZombieLoad: Cross Privilege-Boundary Data Leakage on Intel CPUs

#269

Post by DSingularity »

Narishma wrote: post #219
spamizbad wrote: post #147

Earlier quoted context omitted.

Step one: switch to in-order cores. Step two: cheekily author a Medium article titled Tomasulo's Algorithm Considered Harmful

Are in-order cores even fast enough to render a Medium article?

Yes, but software needs to be rewritten.

Re: ZombieLoad: Cross Privilege-Boundary Data Leakage on Intel CPUs

#270

Post by rarecoil »

bijant wrote: post #192
fakwandi_priv wrote: post #114

Apparently Intel attempted to play down the issue by trying to award the researchers with the 40,000 dollar tier reward and a separate 80,000 dollar reward as a "gift" (which the researchers kindly denied) instead of the maximum 100,000 reward for finding a critical vulnerability. Intel was also planning to wait for at least another 6 months before bringing this to light if it wasn't for the researchers threatening t…

Intel has abused the responsible disclosure process for economic gain. Their Leadership was not interested in a repeat of the spectre and meltdown impact on their stock price and made the (most likely accurate) assessment, that recurring news of intel vulnerabilities would harm their stock more than delay and cumulated release. As a result Academic Researchers were denied some of the credit they would otherwise have…

> The public has to be warned, even if no effective mitigation is available. If for a subset of the vulnerabilities, AMD and ARM are not affected then security conscious users could have been reducing their exposure by utilizing competitors chips.

The way Intel has been handling these security issues, I am going to avoid buying Intel whenever possible moving forward, regardless of if they have slight performance or power gains over competitors. The way to speak negatively toward corporate governance in this case is to vote with my wallet.

Post reply on HN