3 ms·

> RISC-V is new and sexy. RISC-V is pretty shoddy (M mode, a separate hypervisor mode instead of proper orthogonality, CSRs), but that's exactly what I'd expec

> RISC-V is new and sexy. RISC-V is pretty shoddy (M mode, a separate hypervisor mode instead of proper orthogonality, CSRs), but that's exactly what I'd expect from thesis-driven development (remember that RISC-V was an academic project for a long time). Holding their feet to the fire so that they undo some of that damage seems to be a pretty good idea to me, and if it's PowerPC what it takes to do that, that's not the worst choice IMHO.

gridlockd 7y ago
I'm sure your technical arguments are well-reasoned, but I'm not changing my mind. I already made a modest emotional investment into RISC-V.
monocasa 7y ago
M mode isn't a hypervisor mode. It's more like x86 System Management Mode, or ARM's EL3. Hypervisor was originally going to be a separate H mode, but they made it orthongonal with S mode instead as a sort of bank switch. And if CSRs are bad, then POWER's SPRs are bad; they're basically the same thing except POWER makes much less effort to be consistent or introspectable. POWER is way more braindead in it's supervisor state. For instance they finally gave you a sane radix tree page table with POWER9, but now you can't address all the virtual address space you could before, which, yes, is its own problem for some systems.
- pgeorgi 7y ago
  > M mode isn't a hypervisor mode. I'm well aware. I should have used a semicolon. I take issue with both m mode and hypervisor mode.
  - monocasa 7y ago
    What do you take issue with M mode? And they removed H mode.
    - pgeorgi 7y ago
      > 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.)

gridlockd 7y ago

I'm sure your technical arguments are well-reasoned, but I'm not changing my mind. I already made a modest emotional investment into RISC-V.

monocasa 7y ago

M mode isn't a hypervisor mode. It's more like x86 System Management Mode, or ARM's EL3. Hypervisor was originally going to be a separate H mode, but they made it orthongonal with S mode instead as a sort of bank switch. And if CSRs are bad, then POWER's SPRs are bad; they're basically the same thing except POWER makes much less effort to be consistent or introspectable. POWER is way more braindead in it's supervisor state. For instance they finally gave you a sane radix tree page table with POWER9, but now you can't address all the virtual address space you could before, which, yes, is its own problem for some systems.

pgeorgi 7y ago
> M mode isn't a hypervisor mode. I'm well aware. I should have used a semicolon. I take issue with both m mode and hypervisor mode.
- monocasa 7y ago
  What do you take issue with M mode? And they removed H mode.
  - pgeorgi 7y ago
    > 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.)