
Linux to begin tightening up ability to write to CPU MSRs from user-space - rbanffy
https://www.phoronix.com/scan.php?page=news_item&px=Linux-Filter-Tightening-MSRs
======
strstr
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.

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

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

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

~~~
segfaultbuserr
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.

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

~~~
segfaultbuserr
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.

~~~
kinghajj
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
Not sure, but I believe root or equivalent (CAP_SYS_RAWIO) privilege is always
needed to write MSR, nothing has changed here.

------
MintelIE
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.

