On Thu, Aug 9, 2012 at 4:41 PM, Andreas Jaeger
Let’s call them “Machine Owner Keys” or MOKs for short.
...
The second is the so called “Boot Services Only Variables.” These variables are accessible to any code that runs during the boot process. After the boot process ends and before the OS starts, the bootloader must call the ExitBootServices() call. After that, these variables are no longer accessible, the OS can’t touch them.
...
An important aspect to remember is that all of this happens during boot time, only verified code is executing now. Therefore, only a user present at the console can say, “I want to use my own set of keys.” It can’t be malware or a hacker with remote access to the OS because hackers or malware can only change the file, but not the hash stored in the “Boot Services Only” variable.
I want to make sure I understand. So, if I'm compiling code on my own box I install a MOK validation key via the console (prior to the ExitBootServices() call) and I use my MOK signing key to sign any kernels I build. That seems easy enough. But what if I want to compile a kernel for a physically remote computer, what do I do? I'm thinking of the situation of a rented 1u (or similar) box far from my location. I've rented those before that I could have the provider dump a default OS (opensuse/SUSE, fedora/Redhat) on and then I take it from there. As part of the provisioning process, does the provider now need to create a MOK for that machine and install it, then give me the signing cert so I can build kernels for the box. Will the same thing be true of a Redhat provisioned remote server? If all of linux has a similar provisioning scheme, it should fly. If the openSUSE/SUSE provisioning scheme is unique, I suspect a lot non-compliance on the part of remote server providers. Thanks Greg -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org