On 08.03.23 13:28, Joey Lee wrote:
Yes, MSR will be locked-down. You may want to look at msr-safe:
Hi, I am afraid it is useless in principle. Their approach is fundamentally flawed and unfixable, IMHO. The whole point of SecureBoot is that unsigned stuff is untrusted to get unfiltered access to HW, let alone direct access. That in turn does mean that you cannot let unsigned stuff, which includes all of user space, define what parts of the HW are "harmless" Their interface of **/dev/cpu/msr_allowlist** is specifically designed for that. To quote the README: # OVERVIEW msr_safe provides controlled userspace access to model-specific registers (MSRs). It allows system administrators to give register-level read access and bit-level write access to trusted users in production environments. And that is _precisely_ what you must not do. And cryptographically signing users is probably a human rights violation This is at best a work around. We have to face up to a basic truth. If you want a cryptographically secured kernel space there are fundamental limits to user space drivers. And with MSRs you are way beyond them. If you want to do this, write a conventional driver for a platform character device and send it upstream. And you need to implement your operations as semantically meaningful _inside_ kernel space. You cannot have an interface for writing opaque values generated in user spaces to MSRs. If you are looking for a temporary quick fix maybe this may help. But other than that, forget it. Regards Oliver