4 ms·

> What do you take issue with M mode? As you say, it's similar to x86's SMM, and like all firmware stuff that survives beyond the kernel entry point, is someth

> What do you take issue with M mode? As you say, it's similar to x86's SMM, and like all firmware stuff that survives beyond the kernel entry point, is something that I don't trust, and where experience tells me that it's a venue for vendors to mess things up. One of the hardest issues with real time computing on x86 is... SMM. One of the easiest ways to bypass security on x86 is... SMM. The workaround for "securing" SMM is to sprinkle virtualization on it (STM: because more virtualization is always better), which only adds more complexity (and messes up real time computing even more). And all that closed source because SoC/firmware vendors quickly and happily assume that such modes are owned by them, to the detriment of whoever wants to know what their machine is doing. Not having such a mode helps keep vendors honest: if there's a need for a workaround, document it and kernel developers can implement it (and they will). None of that "install this firmware update that we don't tell you anything about in order to hopefully be slightly more secure than yesterday" crap. > And they removed H mode. Well, that's an improvement. Thanks for making me look it up again. One down, one to go.

wolfgke 7y ago
> One of the hardest issues with real time computing on x86 is... SMM. One of the easiest ways to bypass security on x86 is... SMM. The workaround for "securing" SMM is to sprinkle virtualization on it (STM: because more virtualization is always better), which only adds more complexity (and messes up real time computing even more). A question: To my knowledge, SMM runs in ring -2, while virtualization runs in ring -1 (i.e. is less privileged than SMM). So how can one "secure" SMM by using virtualization?
- pgeorgi 7y ago
  All rings below 0 are informal. Generally, SMM can control the environment of an hypervisor, so that's where that hierarchy comes from. But: SMM is a relatively complete x86 computing environment. You can switch between real/protected/long mode, you can set up page tables. Apparently the only thing that is truly locked down is receiving further SMIs. I was meaning to try to just run full Linux with processes within SMM, and I see no reason why that shouldn't work (except that it's probably a less well exercised CPU state, so I half expected to experience all kinds of oddities in that state). Never got to try that, though. And then I learned that it seems that you can just enter virtualization modes while in SMM, although maybe not on all CPU generations. See https://github.com/jyao1/STM/blob/master/Stm/StmPkg/Core/Init/VmcsInit.c#L135 https://github.com/jyao1/STM/blob/master/Stm/StmPkg/Core/Ini... So SMM is more akin to AArch64's hierarchy (although I have no idea who came up with it first): there are privilege levels 0-3 (on x86: regular operation) and there are "secure" privilege levels 0-3 (on x86: SMM) - just without the security (see all the attacks successfully mounted against SMM). (and yes, I'm also critical of the secure level stuff on ARM: Yet another place where I've seen crappy SoC vendor code routinely hidden. Although to their credit, ARM seems to have designed that mode with security from the start while SMM was more of a hackjob to support the first 386-based laptops which then grew way larger than it should have, like everything in 8086.)

wolfgke 7y ago

> One of the hardest issues with real time computing on x86 is... SMM. One of the easiest ways to bypass security on x86 is... SMM. The workaround for "securing" SMM is to sprinkle virtualization on it (STM: because more virtualization is always better), which only adds more complexity (and messes up real time computing even more). A question: To my knowledge, SMM runs in ring -2, while virtualization runs in ring -1 (i.e. is less privileged than SMM). So how can one "secure" SMM by using virtualization?

pgeorgi 7y ago
All rings below 0 are informal. Generally, SMM can control the environment of an hypervisor, so that's where that hierarchy comes from. But: SMM is a relatively complete x86 computing environment. You can switch between real/protected/long mode, you can set up page tables. Apparently the only thing that is truly locked down is receiving further SMIs. I was meaning to try to just run full Linux with processes within SMM, and I see no reason why that shouldn't work (except that it's probably a less well exercised CPU state, so I half expected to experience all kinds of oddities in that state). Never got to try that, though. And then I learned that it seems that you can just enter virtualization modes while in SMM, although maybe not on all CPU generations. See https://github.com/jyao1/STM/blob/master/Stm/StmPkg/Core/Init/VmcsInit.c#L135 https://github.com/jyao1/STM/blob/master/Stm/StmPkg/Core/Ini... So SMM is more akin to AArch64's hierarchy (although I have no idea who came up with it first): there are privilege levels 0-3 (on x86: regular operation) and there are "secure" privilege levels 0-3 (on x86: SMM) - just without the security (see all the attacks successfully mounted against SMM). (and yes, I'm also critical of the secure level stuff on ARM: Yet another place where I've seen crappy SoC vendor code routinely hidden. Although to their credit, ARM seems to have designed that mode with security from the start while SMM was more of a hackjob to support the first 386-based laptops which then grew way larger than it should have, like everything in 8086.)