> Thus they decided to do permissions checking in parallel with other operations, leading to Spectre

No. Leading to Meltdown. Spectre is fundamental to the way we approached any speculative execution until now.

Spectre variant 2 is not fundamental to speculative execution. It can be fixed by tagging the indirect branch predictions with the full virtual address and the ASID, and flushing it together with the TLB.

Any idea what will be the solution? Keep more speculative data in the pipeline? Performance penalties on security faults? Complex rollback?

you could certainly extend the unused transactional support to do a chandy-lamport thing, with the difference that when you run out of space isolated cache versions, you just can't speculate any more.

it would be a lot of machinery

you could also do latency hiding with smt instead of trying to fight it head-on with speculation. ultimately probably more productive, but either the compiler or the programming model or the user has to expose that concurrency.

If all speculation used a separate cache that is only committed on retirement, that should keep the side channels at bay.

> This brings to mind articles and discussions I read in the early 90s about differences in performance between running in real (or "unreal") mode and protected mode

I remember a 10 years old Microsoft Research project that implemented an OS that would use the .NET managed runtime to implement security. IIRC, they had interesting differences with CPU memory isolation off.

I like the idea that you don't need hardware barriers to isolate programs when they are lobotomized.

You're speaking of Singularity and it's "software isolated processes", which amounted to static verification of IL before AOT compiling it to x86. From the perspective of Sing#, the only way to express IPC was in the form of protocols, which were essentially formalized function call dances between two processes.

Singularity would be just as vulnerable to the recent bugs as contemporary OSes are, possibly more so because there is even less timing uncertainty when crossing privilege domains, making the attacks even easier

Cosmos OS is another .NET-based OS toolkit that does this. Here's a video of one of the developers talking about this, and other things: https://channel9.msdn.com/Shows/On-NET/Chad-Z-Hower-aka-Kudz...

Plenty of embedded CPUs don't have MMUs. Having done multi-"process" programming on them, it is hard to appreciate how nice basic address space protection is from a debugging perspective.

does modern x86 even support real mode?

AFAIK all x86 processors start in real mode.

Intel tried making a 386 variant with only protected mode a long time ago, and it didn't sell very well: https://en.wikipedia.org/wiki/Intel_80376

32-bit protected mode only, but with all support for paging and virtual memory removed? I can see why that combination never really caught on.

They made it from 1989 to 2001 so it must have been okay for the embedded market that it targeted.

It might have a better chance these days, with UEFI becoming the default.

Rumor is Intel is trying to get rid of the BIOS and just start the processor in protected mode

Sure it does. All x86 CPUs boot up in real mode, for example. Bootloaders are written in real mode.

> Bootloaders are written in real mode.

Not when the bootloader is an UEFI application. UEFI puts the processor into 32 bit protected mode or typically long mode (64 bit). So when your bootloader that is implemented as an UEFI application is started, you are already out of real mode.