Paul A. Clayton (paaronclayton.delete@this.gmail.com) on September 14, 2021 9:45 am wrote:
> Or use a PLB

Ugh. Then you'd be better off just doing the TLB instead.

If the thinking is "I can look up the data early, and use a separate permission lookaside buffer to check the access later", you end up with the situation we saw with Meltdown - happily using data speculatively, and leaking it like mad.

So no, it's not ok to look up permissions "later".

So a PLB is absolutely the wrong answer. The traditional reason for it ("make it not be in the critical path for the data access") is simply unacceptable due to security reasons.

Now, what I could see working is having multiple levels of permission checking, where the checking done for security reasons could be done with a much bigger granularity.

For example, you might do things like VMM and kernel protections based purely on address, with no table lookup at all (or, rather, a very small fixed table that is set up statically). So you might have some high-level "this protection domain can access this virtual area".

Do those synchronously with the lookup, protecting against Meltdown - and then accept semantics like "within this permitted set of virtual addresses, data may leak through side channels", because you check the per-page permissions much later (and maybe <much later - at instruction retirement time).

But even then a PLB sounds like the wrong thing to do. You might as well just do the accesses purely by virtual address, and then check the exact bits from a TLB lookup much later, so the TLB just isn't on the critical path. And you need that TLB for the cache miss case anyway, so it's not like you can replace the TLB with a virtual cache and a PLT.

But note that the above "relaxed virtual address region" model requires architectural support, so it's not invisible. In practice, it would probably work very well (ie just a few special range registers, so that the OS could then carve out the area it wants to protect, and user space that does JIT protections could say "this is the safe access area" etc).

Basically it would allow the different security rings to say "within this range, you can speculate accesses and leak data - but only within this range". That obviously still requires that you check the full cache tags and don't leak data that way.

But even if you accept the information leak semantics, you still want those protections at a page level (and access/dirty bits!) to still be semantically enforced. And they can't be based on some big range thing - they need a page table walker, and I do not believe a PLB helps with that problem at all. It requires the exact same indexing, it would just make the data behind it smaller - but I don't think that is a sufficiently big advantage to make it worth it.

Or is there some PLB upside I am missing?

Linus