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 -- To unsubscribe from this list: send the line "unsubscribe linux-efi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html