On Wed, Mar 08, 2023 at 02:16:33PM +0100, Oliver Neukum wrote:
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.
Of course you can. Same as you can have nVidia modules and whatnot. The premise of secure boot as designed is that they cannot be enabled *automatically*, the user has to give consent in the MOK dialog that appears on boot. Thanks Michal