In Linux > 5.7, the field mm_struct.mmap_sem is not available. Therefore, the POC does not build.

It would be good to have a permanent link to the current filter settings to be able to share it.

add buttons to open PRs on GH (maybe also GH stars) and to cite the paper with an extended bibtex entry with a note to the website

We should add a paragraph to each attack node in the tree listing "known defenses" and links

Described here and here, this actually also includes an interesting sub-instance of MD-GP. The paper and deep-dive are not very clear on the exact interaction with #GP faults, but afaik some of the attacks abuse that transient execution continues with wrong segement selectors after a faulting WRFSBASE. Hence, we should figure out and clearly describe the MD-GP behavior and update the tree accordingly.

Under "Literature" in the README, the links for Meltdown, Spectre, and Foreshadow return 404s from GitHub.

POC just support x86
How to change code to support ARMv8?

Browser: Chrome 80.0.3987.132
OS: Windows 1909

Uncaught Error: missing: 9
    at e (index.js:formatted:3765)
    at Object.n.generateNestedData (index.js:formatted:1149)
    at Object.refresh (index.js:formatted:925)
    at toggleMeltdownSpectre (filter.js:57)
    at filter (filter.js:107)
    at (index):406

Reproduce

1. Open https://transient.fail/
2. Deselect all vendors
3. Select "Intel"

Selecting either "ARM" or "AMD" does not give this error.

We should incorporate https://lviattack.eu/ into the tree. Either as an addition to the MD subtree or a separate branch? Given the symmetry with existing MD-type attacks, Id argue for extending the MD subtree instead of creating a new branch. Proposed plan RFC:

• rename Meltdown-type to Meltdown/LVI-type to reflect that MD is not anymore only about "melting down" protection domains by leaking
• update each MD leaf with a "leakage" and "injection" subsection briefly describing the impact of the leakage/injection angles, if applicable
• add NULL as an extra leaf for the last-level u-arch buffer split. At least for MD-US-NULL, we can also mention EchoLoad in the "leakage"-oriented subsection, as it abuses NULL forwarding to break ASLR which leaks side-channel info.
• add a new MD-PPN node to describe Foreshadow-EPCM SGX leakage attacks and LVI-PPN-L1D attacks; for completeness we should prob also add MD-RSVD

Ideas, feedback?

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?

some variants in the accepted paper, public at https://mdsattacks.com/files/fallout.pdf are not yet in tree

Described here and here; "Snoopy" seems to be a special type of Foreshadow/L1TF; not sure how this would fit into the classification tree? It doesn't seem that snoops are a new type of faults or assists, but maybe we can mention the technique under the various -L1 leaves? Would probably require more experimentation as well..

On certain processors and under certain conditions, data in a modified cache line that is being returned in response to a snoop may also be forwarded to a faulting, microarchitectural assist, or Intel® Transactional Synchronization Extensions (Intel® TSX) asynchronous aborting load operation to a different address that occurs simultaneously.

It would be good to have a permanent link (i.e., a URL hash) for every node.

would be a nice feature to have a "timeline" feature where you can drag a slider to see how the transient exec landscape and each of the attack nodes in the tree have been explored/disclosed over time (eg 2018 era vs 2019 era)

https://www.vusec.net/projects/crosstalk/

we should probably improve the tikz export for the JavaScript tree to be a minimal self-contained LaTeX document with all the necessary packages in the header