6 ms·

MSRs are not your ordinary registers, they are low-level registers for configuring major settings on the CPU. > Think performance counter MSRs, MSRs with stick

MSRs are not your ordinary registers, they are low-level registers for configuring major settings on the CPU. > Think performance counter MSRs, MSRs with sticky or locked bits, MSRs making major system changes like loading microcode, MTRRs, PAT configuration, TSC counter, security mitigations MSRs, you name it. I think the only legitimate uses of MSRs in userspace today is changing power-management related settings and performance profiling, which should be managed by the kernel anyway. I welcome this move. PaX/grsec had an option to block MSR accesses for years.

ghaff 6y ago
While I don't know for a fact if MSRs were used in this case, I was at a presentation a few months back where a security researcher (Kit Murdock) used under-voltaging to get data out of a secure enclave (SGX). "Plundervolt is an attack on Intel SGX enclaves, which are trusted execution environments. We showed that we can get secrets out of SGX enclaves by lowering the CPU voltage while it is performing calculations. Plundervolt is a problem because SGX has an attacker model that says, “Even if you’re root, you should not be able to look inside my encrypted area.” " https://research.redhat.com/wp-content/uploads/2019/12/RRQ-Vol2-1.pdf https://research.redhat.com/wp-content/uploads/2019/12/RRQ-V...
- bserge 6y ago
  Intel's solution? "Just disable voltage control, teehee" Afaik, if you need the best security on Intel chips, disabling Hyper Threading is still a must :/ Wtf are they doing...
  - nameless912 6y ago
    Blowing up 15 years of market dominance through mismanagement and hubris?
  - ghaff 6y ago
    Or AMD. One can argue about specific exploits but there are plenty of serious security folks who recommend turning off lots of performance features if you really want to be safe.
    - Symmetry 6y ago
      I do wish there was some sort of "1 process per physical core" rule you could apply at the scheduler level to get most of the benefit with fewer risks. Or maybe isolate the handling of untrusted code like browser javascript, pdfs, etc.
      - secondcoming 6y ago
        You can tell the kernel to not make certain cores available to the scheduler (isolcpus)
        Symmetry 6y ago
        Yes, but that doesn't help if I want a virtual core to only be available to threads belonging to the same process as the thread on the other virtual core. I suppose syscalls make the idea not work anyways.
      - WJW 6y ago
        Step 1: Buy lots of raspberry pis. Step 2: Run 1 process per pi. Step 3: Enjoy freedom from spectre-related problems! Optional step 4: Move everything back to Intel/AMD when management realizes why they went for multiple processes per box in the first place. Money rules everything around us.
        Symmetry 6y ago
        If I'm willing to give up long pipelines and out of order execution for security I'd at least go for a Project Denver chip or something. No need to give up all the single thread performance, or multiple cores sharing a memory pool. Or more likely a chip with a ton of ARM A5* cores on it due to availability. EDIT: Wait, it looks like I could actually get a Drive AGX for $700 on Newegg[1] and they seem to have about 40% the single thread performance of a Ryzen[2]. So actually not out of the question if I was willing to give up more for security than I actually am. [1]https://www.newegg.com/nvidia-jetson-agx-xavier-32gb-256-bit-lpddr4x-137gb-s/p/N82E16813190012 https://www.newegg.com/nvidia-jetson-agx-xavier-32gb-256-bit... [2]https://www.phoronix.com/scan.php?page=article&item=nvidia-jetson-xavier&num=4 https://www.phoronix.com/scan.php?page=article&item=nvidia-j...
  - wmf 6y ago
    Would you prefer if they told you to just buy a new CPU... which isn't even available yet?
Wowfunhappy 6y ago
And also, because it's Linux, anyone who really needs this for some kind of niche reason can recompile the kernel, right?
- segfaultbuserr 6y ago
  It's even better - you just need to change your boot parameters. > This behavior right now can be toggled via the msr.allow_writes= kernel module paramrter with on/off/default. Should legitimate use-cases come up where writes to MSRs from user-space are still desired, they may add the infrastructure to selectively grant/deny access to specific MSRs and ensure they are sanitized by the kernel. Similar hardware restrictions already exists in the kernel, for example, by default the kernel restricts access to I/O memory since it's a dangerous, low-level zone, but if you really need to for some reasons (e.g. reflash your BIOS), you can boot with "iomem=relaxed" to turn it off. Treating MSR registers in the same way is very reasonable.
  - Wowfunhappy 6y ago
    Ah, perfect! That seems like exactly the right way to handle things.
  - kinghajj 6y ago
    Is there any clarification on how this MSR whitelisting will be implemented by end users? Or is there just going to be the global "allow_writes" parameters? I'd assume too that even with that parameter set to on, programs accessing the MSRs will still need the SYS_RAWIO capability.
    - segfaultbuserr 6y ago
      Not sure, but I believe root or equivalent (CAP_SYS_RAWIO) privilege is always needed to write MSR, nothing has changed here.
- bserge 6y ago
  Thank God for that (niche reason being fine grained performance and thermal management on inadequately cooled machines, which is... all of them :D)
lima 6y ago
> I welcome this move. PaX/grsec had an option to block MSR accesses for years. On recent kernels, MSRs writes are disabled by default even by the upstream kernel when the kernel is in lockdown mode (like when using Secure Boot).
- kinghajj 6y ago
  Yup, I just wrote a blog post about recompiling the msr module and signing it with a MOK, as a way to keep undervolting functional while using SecureBoot. https://kinghajj.github.io/blog/undervolting-with-secureboot-in-linux/ https://kinghajj.github.io/blog/undervolting-with-secureboot...
  - pwdisswordfish2 6y ago
    That is a well-written blog post. Thanks for sharing. Wondering if I can do this with a BSD kernel.
Const-me 6y ago
Timestamp counter have legitimate uses, the combination of resolution and access cost is unprecedented. I use them when I need timestamps for events which happen at 1MHz or more. On modern CPUs these counters even run at stable frequency, unaffected by scaling.

ghaff 6y ago

While I don't know for a fact if MSRs were used in this case, I was at a presentation a few months back where a security researcher (Kit Murdock) used under-voltaging to get data out of a secure enclave (SGX). "Plundervolt is an attack on Intel SGX enclaves, which are trusted execution environments. We showed that we can get secrets out of SGX enclaves by lowering the CPU voltage while it is performing calculations. Plundervolt is a problem because SGX has an attacker model that says, “Even if you’re root, you should not be able to look inside my encrypted area.” " https://research.redhat.com/wp-content/uploads/2019/12/RRQ-Vol2-1.pdf https://research.redhat.com/wp-content/uploads/2019/12/RRQ-V...

bserge 6y ago
Intel's solution? "Just disable voltage control, teehee" Afaik, if you need the best security on Intel chips, disabling Hyper Threading is still a must :/ Wtf are they doing...
- nameless912 6y ago
  Blowing up 15 years of market dominance through mismanagement and hubris?
- ghaff 6y ago
  Or AMD. One can argue about specific exploits but there are plenty of serious security folks who recommend turning off lots of performance features if you really want to be safe.
  - Symmetry 6y ago
    I do wish there was some sort of "1 process per physical core" rule you could apply at the scheduler level to get most of the benefit with fewer risks. Or maybe isolate the handling of untrusted code like browser javascript, pdfs, etc.
    - secondcoming 6y ago
      You can tell the kernel to not make certain cores available to the scheduler (isolcpus)
      - Symmetry 6y ago
        Yes, but that doesn't help if I want a virtual core to only be available to threads belonging to the same process as the thread on the other virtual core. I suppose syscalls make the idea not work anyways.
    - WJW 6y ago
      Step 1: Buy lots of raspberry pis. Step 2: Run 1 process per pi. Step 3: Enjoy freedom from spectre-related problems! Optional step 4: Move everything back to Intel/AMD when management realizes why they went for multiple processes per box in the first place. Money rules everything around us.
      - Symmetry 6y ago
        If I'm willing to give up long pipelines and out of order execution for security I'd at least go for a Project Denver chip or something. No need to give up all the single thread performance, or multiple cores sharing a memory pool. Or more likely a chip with a ton of ARM A5* cores on it due to availability. EDIT: Wait, it looks like I could actually get a Drive AGX for $700 on Newegg[1] and they seem to have about 40% the single thread performance of a Ryzen[2]. So actually not out of the question if I was willing to give up more for security than I actually am. [1]https://www.newegg.com/nvidia-jetson-agx-xavier-32gb-256-bit-lpddr4x-137gb-s/p/N82E16813190012 https://www.newegg.com/nvidia-jetson-agx-xavier-32gb-256-bit... [2]https://www.phoronix.com/scan.php?page=article&item=nvidia-jetson-xavier&num=4 https://www.phoronix.com/scan.php?page=article&item=nvidia-j...
- wmf 6y ago
  Would you prefer if they told you to just buy a new CPU... which isn't even available yet?

Wowfunhappy 6y ago

And also, because it's Linux, anyone who really needs this for some kind of niche reason can recompile the kernel, right?

segfaultbuserr 6y ago
It's even better - you just need to change your boot parameters. > This behavior right now can be toggled via the msr.allow_writes= kernel module paramrter with on/off/default. Should legitimate use-cases come up where writes to MSRs from user-space are still desired, they may add the infrastructure to selectively grant/deny access to specific MSRs and ensure they are sanitized by the kernel. Similar hardware restrictions already exists in the kernel, for example, by default the kernel restricts access to I/O memory since it's a dangerous, low-level zone, but if you really need to for some reasons (e.g. reflash your BIOS), you can boot with "iomem=relaxed" to turn it off. Treating MSR registers in the same way is very reasonable.
- Wowfunhappy 6y ago
  Ah, perfect! That seems like exactly the right way to handle things.
- kinghajj 6y ago
  Is there any clarification on how this MSR whitelisting will be implemented by end users? Or is there just going to be the global "allow_writes" parameters? I'd assume too that even with that parameter set to on, programs accessing the MSRs will still need the SYS_RAWIO capability.
  - segfaultbuserr 6y ago
    Not sure, but I believe root or equivalent (CAP_SYS_RAWIO) privilege is always needed to write MSR, nothing has changed here.
bserge 6y ago
Thank God for that (niche reason being fine grained performance and thermal management on inadequately cooled machines, which is... all of them :D)

lima 6y ago

> I welcome this move. PaX/grsec had an option to block MSR accesses for years. On recent kernels, MSRs writes are disabled by default even by the upstream kernel when the kernel is in lockdown mode (like when using Secure Boot).

kinghajj 6y ago
Yup, I just wrote a blog post about recompiling the msr module and signing it with a MOK, as a way to keep undervolting functional while using SecureBoot. https://kinghajj.github.io/blog/undervolting-with-secureboot-in-linux/ https://kinghajj.github.io/blog/undervolting-with-secureboot...
- pwdisswordfish2 6y ago
  That is a well-written blog post. Thanks for sharing. Wondering if I can do this with a BSD kernel.

Const-me 6y ago

Timestamp counter have legitimate uses, the combination of resolution and access cost is unprecedented. I use them when I need timestamps for events which happen at 1MHz or more. On modern CPUs these counters even run at stable frequency, unaffected by scaling.