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 use

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.