Re: Do not allow MSR or Embedded Controller writes from userspace in secure boot case

[Thomas Renninger <trenn-l3A5Bk7waGM@public.gmane.org>]

On Wednesday, November 07, 2012 11:51:06 PM H. Peter Anvin wrote:
> On 11/07/2012 10:54 PM, Matthew Garrett wrote:
> > Is there a case where modifying MSRs or EC registers can cause
> > arbitrary code execution?
> 
> For MSRs we could have a whitelist of permitted MSRs, but allowing
> general MSR access... no.

BTW: Who decides what is allowed and what is not?

1) hpa?
2) Intel
3) The efi list?
4) The spec?
5) Windows when they threat distributions to revoke their
   key if they do not do this and that?

I guess it should be the spec. I haven't read the details, but
when even Matthew is not sure, it sounds as if this is phrased
rather imprecise. And as Windows is afaik the central key authority
they can enforce their interpretation of the spec for Linux as well?

An example:

I have seen (shortened) a patch like this:

Secure boot: Add a dummy kernel parameter that will switch on Secure Boot mode
+__setup("secureboot_enable=", secureboot_enable_opt);

This is to enforce secure boot restrictions even if
HW does not support UEFI version 2.3.1 (or whatsoever).

I like to have this boot parameter to also work the
other way around:
secureboot_enable=no
and let all secure boot things fall off, only set a
TAINT_INSECURE_BOOT_EVEN_BIOS_REQUESTED_SECURE_BOOT

Can SUSE sign this kernel without fearing to get the key revoked
from Windows?
Can this exist in the mainline kernel?

   Thomas