[openstack-dev] [nova] Testing concerns around boot from UEFI spec

Matt Riedemann mriedem at linux.vnet.ibm.com
Thu Dec 10 14:34:30 UTC 2015

On 12/10/2015 2:21 AM, Ren, Qiaowei wrote:
>> -----Original Message-----
>> From: Sean Dague [mailto:sean at dague.net]
>> Sent: Friday, December 4, 2015 9:47 PM
>> To: openstack-dev at lists.openstack.org
>> Subject: Re: [openstack-dev] [nova] Testing concerns around boot from UEFI
>> spec
>> On 12/04/2015 08:34 AM, Daniel P. Berrange wrote:
>>> On Fri, Dec 04, 2015 at 07:43:41AM -0500, Sean Dague wrote:
>>>> Can someone explain the licensing issue here? The Fedora comments
>>>> make this sound like this is something that's not likely to end up in distros.
>>> The EDK codebase contains a FAT driver which has a license that
>>> forbids reusing the code outside of the EDK project.
>>> [quote]
>>> Additional terms: In addition to the forgoing, redistribution and use
>>> of the code is conditioned upon the FAT 32 File System Driver and all
>>> derivative works thereof being used for and designed only to read
>>> and/or write to a file system that is directly managed by Intel's
>>> Extensible Firmware Initiative (EFI) Specification v. 1.0 and later
>>> and/or the Unified Extensible Firmware Interface (UEFI) Forum's UEFI
>>> Specifications v.2.0 and later (together the "UEFI Specifications");
>>> only as necessary to emulate an implementation of the UEFI
>>> Specifications; and to create firmware, applications, utilities and/or drivers.
>>> [/quote]
>>> So while the code is open source, it is under a non-free license,
>>> hence Fedora will not ship it. For RHEL we're reluctantly choosing to
>>> ship it as an exception to our normal policy, since its the only
>>> immediate way to make UEFI support available on x86 & aarch64
>>> So I don't think the license is a reason to refuse to allow the UEFI
>>> feature into Nova though, nor should it prevent us using the current
>>> EDK bios in CI for testing purposes. It is really just an issue for
>>> distros which only want 100% free software.
>> For upstream CI that's also a bar that's set. So for 3rd party, it would probably be
>> fine, but upstream won't happen.
> Sorry, is there any decision about this? If 3rd CI needs to be added, we could also work on it. BTW, if so, the patches could not be merged when the 3rd CI could not still work, right?
> Thanks,
> Qiaowei
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

We talked about this in the nova meeting today and agreed that as long 
as there is a warning emitted when this is used saying it's untested and 
therefore considered experimental, we'd be OK with letting this into 
mitaka. It's in Intel's best interest to provide functional testing for 
it, but it wouldn't be required in this case.

I'd like the spec amended for that and then I'm +2.



Matt Riedemann

More information about the OpenStack-dev mailing list