Comment by xenadu02 | Hacker News Reader

Comment by xenadu02 | Hacker News Reader

Parent Full thread

Indeed, AMD CPUs don’t speculate loads until the page protection is checked. That alone eliminates whole classes of vulnerabilities.

Cache updates will need to be staged and not “retired” (aka committed and made visible to other cores) until the speculated instructions are retired. That will have some perf impact and cost some die space, but it is hardly fatal.

Whether AVX survives in its current form is an open question. Those 512-bit vector units cost a lot of power. Intel gets away with powering them down when unused, leading to a large delay when the first vector instruction is encountered after an idle period. Powering them up continuously blows their TurboBoost strategy. If they can eliminate the penalty or make the units more power efficient it might not require many changes, otherwise AVX may need to shrink back down to narrower units, or maybe force them through a shutdown cycle on every context switch? Not sure what the solution is here.

On the AVX thing, I think maybe you can eliminate it as a channel for speculative execution attacks by just not speculatively executing AVX-512 instructions when the units are powered down, which also sounds more efficient (it doesn't sound good that, apparently, if (expression_that_is_false) { do_avx_instruction() } can drop your clock speed for several milliseconds if branch prediction guesses wrong! The cost of powering up the AVX units is, I think, much greater than the cost of failing to speculate once.)

In general, I think the problem is that we probably don't know about all possible side channels, and might not for many years. So the approach you suggest - eliminating side channels one by one so that you can't extract information from speculative execution that way - is inherently risky.

I don't know if Intel have done this, but you can design AVX-512 to run on AVX ALUs at half the IPC. You could feasabley design a CPU which has full AVX-512 units powered down and runs instructions at half speed until the full ALUs are powered up.

One you have a CPU of that design, you can eliminate that AVX-512 sidechannel by not sending the signal to power up the full AVX-512 ALUs until a AVX-512 instruction is fully executed.

I'm not sure you could do that in a completely secure processor though; at least not the way you're describing. More ideally the delay would at least be /simulated/ even IF the units were already powered up because of prior instructions. It would be /per thread/ tracking of slow/fast/powered before paths.

Edit: About 10 min after posting the above, I realize that this MIGHT be what your second paragraph is describing, though it isn't as unambiguous.

Would there still be a thermal side channel, if one had access to high enough resolution power monitoring?

No. Simply providing two ways to executate with 256bit or 512bit ALUs is not enough to prevent side channels, you can still time the execution time to read the side channel.

The key to closing the side channel is not allowing speculated instructions to trigger the activation of the 512bit ALUs. Hold off for a few cycles until execution of those instructions is confirmed.

> ...by just not speculatively executing AVX-512 instructions...

See this suggestion a lot. At any given time, a CPU is trying to execute 5-8 u-ops in different execution units every cycle. These 5-8 u-ops must come from instructions somewhere. To have something to do, CPUs need to load dozens, even hundreds of instructions from "the future" using branch prediction. As such, there literally could be hundreds of instructions in its reorder buffer at once. Of these, 5-10 of them might represent branches which cannot been executed due to dependencies but instead have been simply guessed at using branch prediction.

TLDR; that pretty much means that the CPU is always speculating--perhaps 95% of all cycles.

Typical CPU designs do not explicitly track branch dependencies in the reorder buffer. Instead, they either rely on anulling at commit time or clearing the reorder buffer when a mispredicted branch commits. That means the CPU literally has no way of knowing whether it is currently "speculating". To fix this, one would have to add control dependencies to AVX instructions so that they could never execute with branch instructions on which they depend (i.e. earlier on their proper architected path) in-flight. That would almost certainly annihilate performance, which, after all, is the point of AVX instructions.

Powering up the full AVX-512 datapath supposedly takes something like 500 microseconds, and then slows the clock speed for something like 2000 microseconds. If so, you could literally just make every AVX-512 instruction fault when the units are powered down, let the operating system (after an appropriate fence) explicitly authorize powering up the AVX-512 datapath, and have no noticeable performance degradation relative to these enormous costs. And once the units are powered up, there is no side channel problem.

Never speculatively executing AVX instructions will, for bad but not uncommon cases, drop your performance by something like a factor of 10 in cases such as when you perform some AVX operation until a flag is set. I don't think there's any chance of that happening.

I said "not speculatively executing AVX-512 instructions _when the units are powered down_".

Reply on news.ycombinator.com