fyi1183

To play devils advocate, the success of Asian Americans and Jews could also be explained by genetics.

My own biases as well as basic knowledge of the respective cultures makes me fairly certain that it's culture in both cases rather than genetics, though.

Those visible effects (caches being primed by speculative execution) are desirable in many cases though, so it's misleading to say the processor is wrong.

You don't need to model the timing though.

What I'm saying with the type system comment is this: the cache side effects of speculation are desirable most of the time but not always. We should find a way to model data sensitivity in the type system so that a compiler can automatically choose to generate a side-effect-free code sequence where the side effects must be avoided (this assumes a future with ISA extensions that allow telling the CPU to prevent such side effects by blocking the speculative execution).

If you don't feel overwhelmed enough by the misprediction variant of Spectre yet, consider that the cache side effect of speculation is actually desirable in most normal cases, because it helps prime caches with data that is likely to be used in the correct branch as well. Just turning it off is not the right way to solve this.

Perhaps this will finally provide enough incentives to model data sensitivity in the type systems of practical programming languages.

Well, there seems to be a lot of hysteria right now. You mention speculation-based side effects in general, but keep in mind that only data-dependent side effects matter. There aren't that many of those outside the memory system, if any.

You mention idiv, which is an interesting example. Is it actually observable? Without hyper-threading, almost certainly not, because the execution unit reservations should be dropped as soon as the speculated branch is resolved. With hyper-threading? Perhaps, but it shouldn't be too hard to fix if a non-speculated thread always takes precedence over a speculated one, which makes sense anyway.

In both cases there may be leaks in practice, but those should be fixable relatively easily in hardware, and we've already established that hardware fixes are required anyway.

Another case to think about are dependent conditional branches, since those could affect the instruction cache.

It does seem like a good idea to have a strict barrier instruction against speculative execution just to have a fallback mitigation.

The linked advisory 254 claims that SP2 is limited to code after bounds checks and similar when SMEP is used.

This is incorrect: the BTB can be poisoned to speculatively jump anywhere in the text segment of the supervisor.

The solution may lie in a new "non-speculative load“ instruction that delays execution until preceding branches are confirmed.

This would allow keeping the performance of speculative execution in the vast majority of cases, while also fixing the kind of potentially leaking double-indirections that Spectre variant 1 can exploit.

Spectre variant 2 needs to be fixed by isolation of the branch prediction structures, i.e. tagging the BTB and others with the PCID and privilege level.

Honestly, you probably don't even need the barrier in your example. Getting data[a] into the cache is no information leak if the attacker already knows a. That's why the example in the Spectre paper uses an additional level of indirection.

I agree that we'll probably see new attacks in this area for a long time.

That said, the main new ingredient of Spectre seems to be the idea that userspace can poison the branch target buffer to cause speculative execution of arbitrary code in kernel space. That part of the attack should be fairly easy to mitigate with new hardware, by XORing (or hashing) the index into the BTB with a configurable value that depends on the privilege level. So each process has its own "nonce", and they're all different from the kernel's.

Then BTB poisoning won't work unless the attacker knows its own and the other context's nonce. Even if further attacks are found that leak this nonce, they could be mitigated by changing the nonce at regular intervals.

What people usually mean by demand in this context is effective demand, which means people offering money in exchange for goods. That can be increased quite easily, and it makes perfect sense, because people/businesses will produce more goods (which is the definition of increased supply) to chase the offered money.

Your musings about infinite demand and magic production technologies are not entirely uninteresting, but they miss a huge universe of much more interesting and immediately applicable ideas.