- PeterHParticipantJanuary 2, 2018 at 7:10 pmPost count: 41
‘Kernel memory leaking’ Intel processor design flaw forces Linux, Windows redesign
Apparently a flaw in how security is managed with in fight instructions in current Intel processors, when execution switches to system mode, other instructions in flight can come along for the ride and perform part of their operation at the higher privilege level. Sounds to me like operating mode is a global state on these processors. AMD processors appear to avoid this bug. The Mill, designed to have each instruction in flight tagged for thread and turf, sounds like it should avoid this problem.
- This topic was modified 6 years, 1 month ago by PeterH.
- bakul_retiredMemberJanuary 2, 2018 at 8:05 pmPost count: 4
I think even mill would be susceptible to Rowhammer.
Though I should mention that the current bug being discussed (we are speculating that it is about speculative execution across protection boundary) likely won’t be an issue for mill.
- This reply was modified 6 years, 1 month ago by bakul_retired.
- Ivan GodardKeymasterJanuary 3, 2018 at 6:05 amPost count: 689
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.
- PeterHParticipantJanuary 3, 2018 at 6:04 pmPost count: 41
Encrypting spiller frames and PLB tables being written to DRAM sounds like a viable option for higher security situations. Encrypting other traffic would present complications if that same data is used by some other device, such as DMA for a hard drive or network.
You must be logged in to reply to this topic.