Hi; this email is intended mainly to raise awareness of an issue which some people here might care about but be currently unaware of, and to see if anybody already has a plan to deal with it.
The VM System Specification for ARM Processors: http://www.linaro.org/docs/vm-system-specification-arm-processors/ defines the contract between a VM implementaton (like KVM/QEMU or Xen) and an image to run on it (like a distro's ISO installer image). This specification mandates that we boot by treating the image as a UEFI ISO image with a FAT32 filesystem. So the VM (and QEMU in particular) needs to have a custom UEFI firmware image if it wants to support booting these images, and that UEFI needs to understand FAT32.
Unfortunately the Tianocore UEFI implementation, though mostly BSD licensed, has a critical piece which is not. The FAT filesystem driver license is "BSD plus may only be used as part of EFI"; full license text on this web page: http://tianocore.sourceforge.net/wiki/Edk2-fat-driver
This is redistributable, but obviously not Free by either the OSI or Debian Free Software Guidelines definitions. Accordingly it would have to go in Debian "non-free" and other distro equivalents. (This is exactly where the x86 Tianocore-derived UEFI implementation, OVMF, is currently distributed.)
So the default place we're likely to end up if nobody takes any action is that to use typically distributed ISO images with QEMU the end-user will need to install the UEFI blob on their host system from non-free or other distro equivalent (or download it themselves from the upstream Tianocore website, perhaps).
The question then is: is this outcome unacceptable or undesirable to anybody? Is anybody planning some other approach?
Some notes:
(1) The VM spec doesn't require that the VM supports *only* the UEFI ISO image format, so it's not the case that QEMU is useless without the UEFI firmware. For instance, you could have a Free UEFI variant which omitted the FAT driver, and pick one of the other filesystem types that Tianocore supports for your distro's CD images. (Obviously those images would then probably not be able to boot on h/w, and conversely "standard" images wouldn't boot on the Free-UEFI.)
(2) When describing or proposing a solution to this it's important to be clear about the distinction between copyright licensing issues and patent issues. The problem with the tianocore FAT driver is its copyright license. Anybody proposing a reimplementation with a different license needs to consider whether they run into patent problems. (I'm not going to state an opinion either way about whether such a reimplementation would potentially intersect any FAT related patents or whether the MS license for purposes of implementing EFI would avoid problems or not.)
(3) I imagine that a lot of this ground has already been covered when considering x86 and OVMF; the only difference for ARM is that there's no standard Free-licensed alternative firmware, so the problem is a little more acute. If anybody has a pointer to previous discussion or conclusions that might save us some argument.
(4) If the "default outcome" is actually at least not unacceptable to anybody then we can of course simply do nothing...
thanks -- PMM
On 12/12/2014 03:16 AM, Peter Maydell wrote:
The question then is: is this outcome unacceptable or undesirable to anybody? Is anybody planning some other approach?
Highly undesirable.
One of our engineers is evaluating splicing in the FreeBSD VFAT driver which is BSD licensed without the plus. Whether this will be successful or address all possible concerns is an open question, but it is a potential avenue to resolution.
On 13 December 2014 at 00:57, Brendan Conoboy blc@redhat.com wrote:
On 12/12/2014 03:16 AM, Peter Maydell wrote:
The question then is: is this outcome unacceptable or undesirable to anybody? Is anybody planning some other approach?
Highly undesirable.
One of our engineers is evaluating splicing in the FreeBSD VFAT driver which is BSD licensed without the plus. Whether this will be successful or address all possible concerns is an open question, but it is a potential avenue to resolution.
Did you come to any conclusion about the feasibility of this approach?
thanks -- PMM
On 03/06/2015 06:52 AM, Peter Maydell wrote:
Did you come to any conclusion about the feasibility of this approach?
We think it's technically viable but have decided to not pursue it for now. Whether it addresses the other issues is unclear.