Add ARMv8-A Meltdown-AC variants

[cattius]

Unlike on x86, alignment checks on ARMv8-A can cause one of three different exceptions: a program counter alignment fault, a stack pointer alignment fault, or a data abort exception (for any other misaligned address, if alignment checking is enabled). As these are different exceptions rather than simply different ways to trigger the same exception, we should distinguish them in the systematization tree.

Proposal to add:

• Meltdown-AC-PC
• Meltdown-AC-SP
• Meltdown-AC-AD

I'm undecided on the name for the latter - I think AD might be confusing given we also use it for the accessed/dirty page table bit. Two alternatives are Meltdown-AC-G (G for general case) and Meltdown-AC-DA (DA for Data Abort).

This is all assuming we want to keep the tree naming x86-centric, which I think does make sense (rather than adding, for example, Meltdown-SPA for the stack pointer alignment fault). Thoughts?

[jovanbulck]

Sounds interesting! One consideration would be whether there's actually an observable difference between the different AC exceptions on ARM? If not, I'd consider not (yet) making the distinction? Regarding, AC for program/data/stack, we can exclude AC-PC for x86 I think (AC checks are not performed in kernel mode and for program accesses).

Also, one of the problems in the current tree seems that we don't really make it clear what the #AC is used for: MD-AC on AMD would just fwd the unaligned data potentially, while MD-AC-LFB/LP forwards unrelated stale data on Intel. We should find a way to classify/clarify this better? For now it seems at least on Intel AC has mostly been used to trigger various MDS-type leakages..

[cattius]

Hmm. I'm currently not aware of an observable distinction, but it's also quite difficult to test Meltdown-AC-AD on Linux, as the arm64 kernel assumes alignment checking is always disabled. It crashes immediately if you enable it globally (and as far as I know there is no way to enable it just for userspace rather than also in the kernel), so I'd need to write a minimal kernel that can handle alignment checks to test this. Meltdown-AC-SP doesn't leak data on one core I've tested it on, and I haven't tested Meltdown-AC-PC yet. Perhaps a compromise: unless there's more promising results we don't add them as specific variants, but mention in the Meltdown-AC description that this variant encompasses three different exceptions on Armv8-A? I need to update it anyway, as we incorrectly state that Arm is vulnerable (due to an oversight in the PoC).

Edit - completely agree regarding distinguishing what data is leaking. Currently this variant is structured a bit strangely in the tree: in the root Meltdown-AC we essentially discuss Meltdown-AC-REG (but don't refer to it as such), and then distinguish the child variants of Meltdown-AC-LFB and Meltdown-AC-LP. I think it would make sense to amend the root Meltdown-AC description to describe all three possible variants, and add a Meltdown-AC-REG child. (Note: Meltdown-AC-REG is what we believe happens on AMD, and incorrectly thought was happening on Arm.)

So:

• Meltdown-AC
  • Meltdown-AC-LFB
  • Meltdown-AC-LP
  • Meltdown-AC-REG

Edit2: I have found an ARMv8-A core vulnerable to Meltdown-AC-REG using the SP exception, i.e. Meltdown-AC-REG!