5 ms·

So what happens to software with assembly that reads and writes to registers?

by tmaly 6y ago

ComputerGuru 6y ago
The doesn’t have anything to do with the language code was written in. Ultimately all software is assembly. This is about hardware specific registers that control the underlying hardware and can be used for things like controlling oem functionality (brightness, backlight, etc), changing CPU frequency and voltage, etc.
- chungus_khan 6y ago
  Which also doesn't mean you can't write software that does those things (within reason and as configured by the kernel). It just means that you will have to use the appropriate kernel interfaces, as you already should have been.
- duskwuff 6y ago
  > This is about hardware specific registers that control the underlying hardware and can be used for things like controlling oem functionality (brightness, backlight, etc) That sort of functionality is typically handled by the platform controller by sending commands over LPC or I2C busses. CPU MSRs are generally restricted to controlling the behavior of the CPU itself. > changing CPU frequency and voltage, etc. These are often controlled by MSRs, but should be under the direct control of the kernel, not userspace software.
segfaultbuserr 6y ago
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.
        6y ago
rbanffy 6y ago
My guess is that the CPU will fault if you try to directly write them from a user mode process. You could do that via the MSR kernel driver but it'd be the kernel doing it in kernel mode.
- ajross 6y ago
  It will. RD/WRMSR are privileged instructions and will raise an illegal instruction exception if executed outside of ring 0. The kernel has always had a device-level interface to these instructions for the benefit of (properly authenticated) userspace processes. But as a design point, this is being rolled back. There are just so many MSRs in the modern world and so many are trivially system-breaking that it's just not possible to sanely administer an interface like that.
Skunkleton 6y ago
This isn't about hand-coded assembly that has rdmsr/wrmsr. This is about the kernel api that allows direct access to these msrs.

So what happens to software with assembly that reads and writes to registers?

by tmaly 6y ago

So what happens to software with assembly that reads and writes to registers?

The doesn’t have anything to do with the language code was written in. Ultimately all software is assembly. This is about hardware specific registers that control the underlying hardware and can be used for things like controlling oem functionality (brightness, backlight, etc), changing CPU frequency and voltage, etc.

chungus_khan 6y ago
Which also doesn't mean you can't write software that does those things (within reason and as configured by the kernel). It just means that you will have to use the appropriate kernel interfaces, as you already should have been.
duskwuff 6y ago
> This is about hardware specific registers that control the underlying hardware and can be used for things like controlling oem functionality (brightness, backlight, etc) That sort of functionality is typically handled by the platform controller by sending commands over LPC or I2C busses. CPU MSRs are generally restricted to controlling the behavior of the CPU itself. > changing CPU frequency and voltage, etc. These are often controlled by MSRs, but should be under the direct control of the kernel, not userspace software.

segfaultbuserr 6y ago

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.
      - 6y ago

rbanffy 6y ago

My guess is that the CPU will fault if you try to directly write them from a user mode process. You could do that via the MSR kernel driver but it'd be the kernel doing it in kernel mode.

ajross 6y ago
It will. RD/WRMSR are privileged instructions and will raise an illegal instruction exception if executed outside of ring 0. The kernel has always had a device-level interface to these instructions for the benefit of (properly authenticated) userspace processes. But as a design point, this is being rolled back. There are just so many MSRs in the modern world and so many are trivially system-breaking that it's just not possible to sanely administer an interface like that.

Skunkleton 6y ago

This isn't about hand-coded assembly that has rdmsr/wrmsr. This is about the kernel api that allows direct access to these msrs.