On 07/08/2014 10:19 AM, Petr Pisar wrote:
> On 2014-07-07, Florian Weimer <fweimer(a)redhat.com> wrote:
>
>> Note that Microsoft's current policy may not allow unrestricted
>> virtualization (KVM or Virtualbox—does not matter) because that "permits
>> launch of another operating system instance after execution of
>> unauthenticated code"—the wording is rather unclear. If Microsoft
>> clarifies that this is forbidden, a future Fedora update will remove
>> this functionality, so you will be forced to disable Secure Boot at this
>> point anyway if you want to continue to use virtualization.
>>
>
Could you elaborate more what "unauthenticated code" is in this case?
>
I think it's code that is not cryptographically tied (indirectly) to one
of the Secure Boot trust roots.
However, I don't really know what Microsoft means. It's conceivable that
they assume we sign all of user space (not just for installation purposes),
and they might have a wrong idea about what we can implement in our system.
Is
> it a userspace tool for controlling in-kernel virtualization (e.g. qemu
> in case of KVM)? Because KVM as a kernel module is signed.
>
It's unclear. One possible interpretation is that virtualization acts as
a barrier because it does not provide access to "real" ring 0 on the host.
It sounds reasonable, but it doesn't really match Microsoft's wording I
quoted above (from a public blog post).
--
Florian Weimer / Red Hat Product Security
--
devel mailing list
devel(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct:
http://fedoraproject.org/code-of-conduct
Thanks everybody for enlighten me about this obscure topic :)
--
--
Sergio Belkin