Reply To: Security on SSOOO processors is HARD

Any core including Mill is susceptible to Rowhammer because RH hits a fault in the DRAM, not in the core. The question is what exploits if any can be achieved by RH style memory mangling. A rights escalation would require causing a user to load a different (more encompassing) turf while staying in the same code and data. The only point at which the turf changes is at entry to or exit from a portal call. On entry the new turf is in the portal structure, which is not writeable by either the creating or entering turf. On exit the resuming turf is in the spiller stack, which is also not writeable by either the exiting or exited-to turf. So to escalate the turf you have to have write access to where the turf is kept, and to get that access you have to have write access to where the keeper is kept, and so on. It’s not clear that there is a bottom turtle to that regression.

There is some code in the micro-kernel that has the rights to modify these saved turf ids and does so: the code that initializes a portal, and the code that does exception handling and thread teardown. So there may be an attack vector there if that code can be given a bogus value from DRAM that it then uses to overwrite a turf. But I don’t think I could do it even if I had the source code and the ability to arbitrarily change a value fetched from DRAM.

An alternative approach would be to try to mess with the PLB tables without changing the turf. Changing the entry as it is created would face the same bottom turtle problem as trying to change the running turf id. However, changing the address range when an entry is loaded to the PLB might be more possible. It is not clear how an attacker would learn where the entry is located; the table is dynamically allocated, he doesn’t have access to the register that holds the base address, and getting access to that register is the bottom turtle again. Still, if the attacker can flush the caches and the PLB, then probe to a valid location not in a WKR, then the line address containing the table entry will be among the next few addresses presented to the pins. But if you have pin-level access to the system you don’t need Rowhammer to change the DRAM values read.

So I won’t say that a Rowhammer crack of the Mill is impossible, but it does seem that it will be as hard as a pin crack, and those are blockable by encrypting pin traffic to DRAM. Fair warning though: this stuff is hard, and I may well be overlooking something.