Ricardo B (ricardo.b.delete@this.xxxxx.xx) on January 15, 2018 6:01 am wrote:
>
> In first approach, killing off a faulty load and any instructions which depend on it seems like a good idea.
> But Meltdown is real. And for some reason, several CPU designers have independently made it possible.

I can pretty much guarantee that Meltdown is easy to fix in hardware without lots of new gates.

Why? The TLB already contains other information that forces the CPU to serialize the load. The memory type - which turns a load into an uncached serialized load - is in the TLB already.

So on some other architectures, this might involve extra hardware and complexity, but not on x86. The complexity is already there. Guaranteed. There is no big new logic that needs to be done - all the pieces are there, all the information is there, it's just that Intel checked the protection (and raises the exception) separately, and didn't feed it into the logic that actually did the access, only into the retirement.

So Intel (and apparently Cortex A75) just tied the protection logic too closely to the exception handling and just made sure the instruction didn't retire. It's not an unreasonable implementation when you think of protections as just the exception that is raised.

But it should absolutely be trivial to just tie that protection check into the "does this load need to be serialized" logic in the memory unit too.

Similarly, the Spectre BTB filling attack should be trivial to just do right in hardware. Just make the BTB use the whole linear address, and preferably add the ASID too (or just flush it on context switch). There should be no software workarounds for that long-term. But unlike Meltdown, that will involve a bigger (wider) BTB array. So that's real extra hardware, although not really any extra complexity.

The bounds check attack we'll just have to live with in software, I suspect. That one is fairly fundamental to speculation.

The thing that annoyed me about Meltdown wasn't that it happened, it was literally that it should be so trivial to get right in hardware, and it is really painful to do in software. The only reason we had to do it in software was that we can modify software after-the-fact in ways hardware can't be.

And the other thing that really annoyed me about this whole thing was the insane and horrible Intel PR piece. Intel actually did a lot of things right, but then somebody decided that they need to put out misleading and horrible PR pieces about how their CPU's are "working as designed". Christ. I was personally so angry about that shit that I was ready to go "never Intel" for a while.

Somebody inside Intel needs to really take a damn hard look at their PR practices, and at their management engine crap. Because while I am annoyed by Meltdown, I understand why it happened and I think it was sad but understandable.

In contrast, their PR people are f*cking incompetent (and whoever ok'ed that weasel-wordy PR needs to have his head checked), and their management engine needs to just be scrapped entirely, and the new version documented and open sourced or something. They need to stop playing games around the constant security issues they have. That thing is pure shit.

Linus