Hi Francois,

I don’t feel that it is the responsibility of the BBR spec or the SystemReady program to describe how the partners are implementing their firmware solutions. And these three categories are not exhaustive. I am not sure what purpose do we serve by providing such a list which we may not even able to make it exhaustive. It is not the intent for BBR spec or the SystemReady program to dictate how our partners implement their firmware. We certainly support OSF effort in OCP but that is responsibility of the OCP badge.

Thanks, -DW

From: François Ozog francois.ozog@linaro.org Date: Monday, October 25, 2021 at 4:51 AM To: Dong Wei Dong.Wei@arm.com Cc: Boot Architecture Mailman List boot-architecture@lists.linaro.org Subject: Re: SystemReady and OCP Checklist Hi Dong,

On Mon, 25 Oct 2021 at 13:45, Dong Wei <Dong.Wei@arm.commailto:Dong.Wei@arm.com> wrote: In 4.4 of BBR when discussing LBBR recipe we do provide a note to point to the OSF checklist. However, SystemReady is not the place to require it. Arm supports both open and commercial firmware.

Indeed. Should we express not a requirement but a categorization so that customers can know what is the firmware level of ownership (valid even with commercial firmware)? Category 1: full open source Category 2: mostly open source with binaries redistribution license (OSF) Category 3: commercial firmware with private redistribution license

Sent from my iPhone

On Oct 25, 2021, at 6:44 AM, François Ozog <francois.ozog@linaro.orgmailto:francois.ozog@linaro.org> wrote:

Hi

back in April we had a workshop on firmware sustainability. Since then a number of discussions related concerns on closed source components in TF-A and U-Boot communities. We are also approaching a technical maturity level on SystemReady that it looks timely to revisit this aspect.

Would it be a good move to adopt the Open System Firmware check list https://www.opencompute.org/wiki/Open_System_Firmware/Checklist as part of SystemReady?

*NOTE1: believe SystemReady is at right level as it addresses compliance of platforms. EBBR is a technical recipe to make it work for a particular environment (like SBBR) and so not the best place to deal with redistribution license of binary blobs and other platform owernship aspects.*

*NOTE2/ Adoption could come in different forms: referring to it, crafting a similar one for SystemReady scope, any other smart ways of doing it.*

Cheers

FF

-- François-Frédéric Ozog | *Director Business Development* T: +33.67221.6485 francois.ozog@linaro.orgmailto:francois.ozog@linaro.org | Skype: ffozog _______________________________________________ boot-architecture mailing list boot-architecture@lists.linaro.orgmailto:boot-architecture@lists.linaro.org https://lists.linaro.org/mailman/listinfo/boot-architecture

IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

-- [https://static.linaro.org/common/images/linaro-logo-web.png] François-Frédéric Ozog | Director Business Development T: +33.67221.6485 francois.ozog@linaro.orgmailto:francois.ozog@linaro.org | Skype: ffozog

IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

On Mon, Oct 25, 2021 at 01:51:34PM +0200, Heinrich Schuchardt wrote:

On 10/25/21 12:43, François Ozog wrote:

...

Hi

back in April we had a workshop on firmware sustainability. Since then a number of discussions related concerns on closed source components in TF-A and U-Boot communities. We are also approaching a technical maturity level

U-Boot is licenced under GPL. You must not include any code which is not licensed under GPL or a compatible license (cf. https://www.gnu.org/licenses/license-list.html) into U-Boot. This disqualifies any closed source component but also open source which is not GPL compatible like OpenSSL.

The BSD-3 license of TF-A is compatible with GPL.

For closed source TF-A components distributed with U-Boot the following GPL exception *MIGHT* apply in some cases:

"However, as a special exception, the source code distributed need not include anything that is normally distributed (in either source or binary form) with the major components (compiler, kernel, and so on) of the operating system on which the executable runs, unless that component itself accompanies the executable."

The GNU GPLv2 "mere aggregation" language must also be mentioned when looking at the license effects here.

If TF-A and u-boot were merely aggregated together on the same storage media then the license of one would not influence the licensing of the other.

I am doubtful that one component being responsible for copying the other into memory would change this.

Daniel.

If you include TF-A within the U-Boot binary, all included TF-A components must comply to the GPL license. This is typically the case if U-Boot SPL loads BL31.

...

on SystemReady that it looks timely to revisit this aspect.

Would it be a good move to adopt the Open System Firmware check list https://www.opencompute.org/wiki/Open_System_Firmware/Checklist as part of SystemReady?

SystemReady should require that the firmware complies to the license requirements of its components.

Open sourcing more firmware components increases the trustworthiness of the platform.

Reading the Open System Firmware Checklist some requirements remain unclear to me: The boot ROM that is part of the SoC lithography mask is firmware. The checklist requires that firmware can be updated which is obviously impossible for the boot ROM.

We need a list of software components that the requirements shall apply to. Besides TF-A and U-Boot, please, consider if secure zone software like OP-TEE modules and trust zone shall be included into the requirement.

Best regards

Heinrich

...

*NOTE1: believe SystemReady is at right level as it addresses compliance of platforms. EBBR is a technical recipe to make it work for a particular environment (like SBBR) and so not the best place to deal with redistribution license of binary blobs and other platform owernship aspects.*

*NOTE2/ Adoption could come in different forms: referring to it, crafting a similar one for SystemReady scope, any other smart ways of doing it.*

Cheers

FF

---

boot-architecture mailing list boot-architecture@lists.linaro.org https://lists.linaro.org/mailman/listinfo/boot-architecture

On Mon, Oct 25, 2021 at 03:59:49PM +0200, Heinrich Schuchardt wrote:

On 10/25/21 15:32, Daniel Thompson wrote:

...

On Mon, Oct 25, 2021 at 01:51:34PM +0200, Heinrich Schuchardt wrote:

...

On 10/25/21 12:43, François Ozog wrote:

...

Hi

back in April we had a workshop on firmware sustainability. Since then a number of discussions related concerns on closed source components in TF-A and U-Boot communities. We are also approaching a technical maturity level

U-Boot is licenced under GPL. You must not include any code which is not licensed under GPL or a compatible license (cf. https://www.gnu.org/licenses/license-list.html) into U-Boot. This disqualifies any closed source component but also open source which is not GPL compatible like OpenSSL.

The BSD-3 license of TF-A is compatible with GPL.

For closed source TF-A components distributed with U-Boot the following GPL exception *MIGHT* apply in some cases:

"However, as a special exception, the source code distributed need not include anything that is normally distributed (in either source or binary form) with the major components (compiler, kernel, and so on) of the operating system on which the executable runs, unless that component itself accompanies the executable."

The GNU GPLv2 "mere aggregation" language must also be mentioned when looking at the license effects here.

If TF-A and u-boot were merely aggregated together on the same storage media then the license of one would not influence the licensing of the other.

I am doubtful that one component being responsible for copying the other into memory would change this.

Think of U-Boot's UEFI variables managed by an OP-TEE module (Standalone MM), or U-Boot (or Linux) invoking PSCI. These are not cases of mere aggregation but come close to the operating system case. But TF-A is not an operating system.

This is very much an example of "each case turns on its own facts".

PSCI is a generic protocol. It is based on traps. Its primary purpose is to decouple components that run at different trust levels. TF-A is not the only implementation. U-boot is not the only client.

Such facts make it unlikely that TF-A would become a derived work of u-boot simply because u-boot gets PSCI services from TF-A.

To be clear I agree there are definitely circumstances that could lead an OP-TEE TA, OP-TEE itself or TF-A being combined with u-boot (rather than aggregated alongside). A OP-TEE TA to assist with variable storage could certainly reach this level, especially if it's interfaces were specifically designed to match the u-boot driver model (although this still may not impact TF-A).

Daniel.