I think it already happened, where the flaw itself was critical and the performance impact was substantial. See Zombieload for reference.

1) https://venturebeat.com/2019/05/14/intel-zombieload-flaw-for...

2) https://zombieloadattack.com/

Can I restate the go question as "is complexity of the machine effectively security by obscurity and effective in practice for reliance upon?"

Really how much unnecessary complexity is traversing boundaries we can shut down or at least gate effectively?

My company has used CICS for this purpose since forever and we're not so much a legacy that you will think about our architecture in this way if we talked about it, but CICS is a very rare interface in this era.

We call it serverless now :-) (I'm joking a bit but there are similarities.)

What's probably going to happen is more isolation. SGX is a target for these vulnerabilities because it's a separate mode of the same processor core which runs normal software; were it on a dedicated core, it wouldn't be vulnerable. In the same way, the kernel can be attacked by user processes (and processes can attack each other) only because they share the same core. So I'd expect to see for instance the kernel running on a set of cores separate from user software (probably using a ring buffer interface for most system calls, like io_uring), and the hardware state being totally flushed when switching a core to another process.

(This is also slower.)

Going to be worse than 30% slower by a lot.

What does this statement even mean?

30% slower for what? What workload? What environment?

I can’t even ask what your source on it being “worse than 30%“ because that statement doesn’t mean anything... people keep attaching percentages to these vulnerabilities that really mean nothing for any general use case, to the point you can’t even compare them to each other!

I imagine your answer is going to be “well these mitigations are going to be more slower than the last ones”

Do these vulnerabilities and the last live on the same hot paths?

Are you privy to some information we’re all lacking here that lets you just throw out a statement like this?

the op seemed to be asking if we should remove speculative execution optimizations entirely to avoid these security problems. if we did that, the execution time, if averaged over all the workloads use, would be more than just 30% slower. the slowdown would be so large that i felt comfortable speaking in vague generalities, rather than providing specific benchmarks which pedants on the internet would also reply to in anger stating that it was not a real world workload or whatever. can’t win, so i don’t try.

OP seemed to be doing no such thing. Period.

If anything they’re asking the opposite! “Should we even be limiting the optimizations at all”

They start with the question “are manufacturers are forced to remove specific optimizations” (which replying to with “going to be worse than 30%” doesn't meaningfully answe) and immediately counter it with the above question “why remove any optimizations” (which your reply also doesn’t answer at all)

Calling out your arm wavy non-statement isn’t pedantry, asking that a comment be more than doomsaying noise isn’t either. Sorry if you feel otherwise.

there are some (non-optimal) estimates in the paper, tl;dr it's not great ;)

some more technical info here https://software.intel.com/security-software-guidance/insigh...

Except how many lay people were running workloads where serializing SGX loads is back breaking?

The tone of the original comment replied to definitely came from personal computing slant...

The problem isn't limited to SGX; it's just that nobody has tried it against e.g. the kernel. If someone figures that out you're going to be seeing that performance hit come there, too.

besides drm stuff like netflix (don't know if it's back breaking there), virtually none, of course

unless someone publishes a very practical attack from userspace, I don't think this will affect personal computing atm