On Sat, 12 Oct 2024 at 10:23, Andrew Cooper [off-list ref] wrote:

quoted

This logic is asymmetric.

For an address in the upper half (canonical or non-canonical), it ORs
with -1 and fully replaces the prior address.

Right. The point is that non-canonical addresses will fault, and
kernel addresses are guaranteed to fault.

And the assumption was that any fault will be sufficient to hide the
result, because otherwise you have meltdown all over again.

When userspace passes in a non-canonical pointer in the low half of the
address space but with bit 47 set, it will be considered a high-half
pointer when sent for TLB lookup, and the pagetables say it's a
supervisor mapping, so the memory access will be permitted to go ahead
speculatively.  Only later does the pipeline realise the address was
non-canonical and raise #GP.

This lets userspace directly target and load anything cacheable in the
kernel mappings.  It's not as easy to exploit as Meltdown on Intel, but
it known behaviour, and been the subject of academic work for 4 years.

It sure was never talked about in kernel circles. I checked my email
archives, and neither

   CVE-2020-12965

nor that

    https://www.amd.com/en/resources/product-security/bulletin/amd-sb-1010.html

is anywhere in my emails, nor does lore.kernel.org find them anywhere either.

Anyway, what's the speculation window size like?

               Linus