Linux to begin tightening up ability to write to CPU MSRs from user-space

https://www.phoronix.com/scan.php?page=news_item&px=Linux-Filter-Tightening-MSRs

by rbanffy • 6 years ago

125 32 6 years ago

tmaly• 6 years 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• 6 years 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• 6 years 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.

segfaultbuserr3• 6 years 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.

ghaff2• 6 years 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-V...

Wowfunhappy2• 6 years ago

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

lima• 6 years 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).

Const-me• 6 years 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.

rbanffy• 6 years 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• 6 years 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• 6 years 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.

kevinoid• 6 years ago

For the curious, I think this article is referring to the LKML thread starting at https://lore.kernel.org/lkml/20200612105026.GA22660@zn.tnic/

Teknoman117• 6 years ago

Guess I'm going to have to port RyzenAdj to a kernel module...

strstr• 6 years ago

I see this is a welcome change, particularly as (opt-in) kernel lockdown support starts to tighten down to the point where it is meaningful. MSR writes from userspace should definitely be disabled by default for locked down kernels.

For flexibility, users should be able to opt out of this (as with the rest of kernel lockdown). Sometimes I just want a holster full of foot-guns. Blanket R/W access to MSRs is that.

There are a lot of fairly powerful MSRs. Some of them might already be restricted for all I know. Here are some examples:

  IA32_SYSENTER_EIP -> the instruction pointer after calling SYSENTER. Similar MSRs exist for the syscall instruction.
  IA32_DS_AREA/PEBS MSRs -> DS_AREA is a pointer that points to a buffer of pointers that are written to by the perf subsystem. Manipulating DS_AREA to point to a user page should let you write ~arbitrary data to the kernel.
  IA32_SPEC_CTRL -> disable some of the speculative execution mitigations.

There are less obviously powerful msrs as well, which probably let you get away with some sketchy-ness:

  APIC_BASE -> you could try to get it mapped into userspace then control the APIC directly. Or you could hide particular kernel writes by moving the apic over another page (there was an attack against SMM based on this a while back).
  X2APIC MSRs -> no need to move the apic base when you could just write to the apic through msrs more directly.
  IA32_EFER -> Unexpected switch from long mode to protected. This can't do anything good.
  MTRRs -> Changing memory types underneath the kernel (potentially restricting access to kernel memory) can't do anything good to the kernel. You could also change the caching behavior, which sounds messy.

Edit: Formatting. This is probably still unreadable on mobile.

MintelIE• 6 years ago

This is good, Intel won't fix the CPU in my old Thinkpad W701ds because it's too old now for a firmware upgrade I guess. But the thing is not only more than fast enough for today's use, it also has 32GB RAM and I just got a couple new Chinese batteries for it. There's no way I'm switching from it, you can't even get a real keyboard in a laptop any more.

If operating systems start to beef up security more aggressively then I won't have to worry so much about having old microcode. OpenBSD is ahead of Linux on this too afaicr, sadly though it doesn't like the Nvidia GPU in my computer.

Linux to begin tightening up ability to write to CPU MSRs from user-space

Related Stories