Downfall Attacks

• SIMD read. All SIMD operations that read wide data (128/256/512 bits) from memory are affected regardless of their function: e.g., vmov* only read, vpxor* read and compute the xor. These general-purpose instructions are used everywhere, e.g., compilers spread wide data reads to optimize memory access routines.

• SIMD write. The only SIMD write operations that are affected are the compress ((v)(vp)compress*) instructions.

• Cryptographic extensions. Cryptographic extensions, including AES-NI and SHA-NI (SHA1 and SHA256), when accepting a memory operand, are affected. Data leaks from these instructions expose plaintext data and the secret key, e.g., AES or HMAC-SHA.

• Fast memory copy. Fast memory copies of various data types: byte, word, dword, qword using rep movs* instructions are affected. These are widely used to speed up common memory operations such as memcpy and memove.

• Register context restore. Special instructions to more efficiently store/restore the register context (e.g., xsave/xrstor) are affected. GDS leaks the register context of both standard registers due to xsave/xrstor and wide registers due to fxsave/fxrstor.

• Direct store The direct store is affected. Intel has recently added support for a direct store instruction that can copy a 64 bytes cache line from a source to a destination address.

It's also important to say that these are not bugs. The design is behaving as intentioned. That the performance differs based off the previous code that the CPU has executed was understood and deameed acceptable because the cost of the alternative was considered too high (either in power, performance or area) than the alternative. That's what it means to be an engineer. You weigh up alternatives and make a choice.

In this case, CPUs became fast enough that the fractional part of a bit per iteration became high enough bandwidth to be exploitable, but it needed someone to demonstrate it for it to be understood in the industry. That changed the engineering decision.

- we diable speculative execution, so every conditional branch goes for 1 cycle to the pipeline depth (5, 10, 20 cycles) to evaluate. Probably a 2x to 3x hit on performance.

- we disable prefetching, so every cache miss now has the full memory latency delay to fill a cache line. 1.2 to 1.3x hit???

- We disable SIMD as per this issue. 4x-8x hit on those parts of the code that usebit.

- If we need to go as far as disabling caching you can now only run instructions at the speed of main memory. 100x hit.

CPUs would only be faster than their 1970s ancestors because the clock speed was now 5GHz and not 1 MGHz.

Generalizing: QA/Test and dev people just think differently.

I served as QA manager for a while. I was fortunate to have worked with some really, really good QA/Test people. They're more rare than good devs.

Some individuals can do well in both worlds.

I've had great devs who were pretty good at test. It seems to me like these devs came from outside of software and CS. Like from aerospace or ballet or history.

I've mentored QA/Test people so they could better automate and manage their work. Then they could pick up tasks like CI/CD, testing scripts, scrub data, etc.

But, in my experience, devs are bad at testing, and just terrible at QA.

Getting enough QA/Test support on a team in the 90s was a tough sell, even though everyone gave lip service to quality.

It's been a long time since I've worked with an actual Test person, dedicated to that role. And that was just 1 person vs 8 devs. So ridiculous.

These days, any kind of "test" is done by "business analysts", whatever that means. And I can't recall the last QA person I've worked with (since my stint as QA Manager in the '90s).

FWIW, I wholly agree with Dan Luu's observations about today's QA/Test standard practice in software vs hardware.