Hi everyone,
Just a reminder that the EBBR biweekly is on today at 15:00 GMT. I've
got the following agenda items:
- Disable U-Boot console for secure boot (Ilias)
- SystemReady IR 2.0 draft requirements
- Any other business
Here are the conference details:
Join Zoom Meeting
https://armltd.zoom.us/j/92081365511?pwd=SFZpRitXUEp3Zy9GM0h3UUZ1b1pnUT09
Meeting ID: 920 8136 5511 Password: 490324
One tap mobile +14086380968,,92081365511#,,#,490324# US (San Jose)
+16465189805,,92081365511#,,#,490324# US (New York)
Dial by your location
+1 408 638 0968 US (San Jose) +1 646 518 9805 US (New York) +1 346
248 7799 US (Houston)
Hi all,
Just a quick note that the EBBR meeting scheduled for today is indeed
on. Ilias and Jose will be presenting the work done on A/B updates which
should be interesting to the EBBR audience.
Here's the agenda and dial in details:
Agenda:
- A/B Update Presentation (Ilias & Jose)
- Requirement to disable or remove command line when secure (Ilias)
Zoom details:
17th Jan 2022, 15:00 GMT
Join Zoom Meeting
https://armltd.zoom.us/j/92081365511?pwd=SFZpRitXUEp3Zy9GM0h3UUZ1b1pnUT09
Meeting ID: 920 8136 5511 Password: 490324
One tap mobile +14086380968,,92081365511#,,#,490324# US (San Jose)
+16465189805,,92081365511#,,#,490324# US (New York)
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.
Just a reminder, the EBBR biweekly is on today (about 15 minutes from
now). I try to send these reminders out the week before, but it fell off
my radar last week. Here is what I have on the agenda for today:
Agenda
* Requirements on A/B update (Ilias)
* Can the OS be responsible for firmware update? (Ilias) - e.g., via
fwupd or similar to stage UpdateCapsule()
* Requirement to disable or remove command line when secure (Ilias)
---
Join Zoom Meeting
https://armltd.zoom.us/j/92081365511?pwd=SFZpRitXUEp3Zy9GM0h3UUZ1b1pnUT09
Meeting ID: 920 8136 5511
Password: 490324
One tap mobile
+14086380968,,92081365511#,,#,490324# US (San Jose)
+16465189805,,92081365511#,,#,490324# US (New York)
Dial by your location
+1 408 638 0968 US (San Jose)
+1 646 518 9805 US (New York)
+1 346 248 7799 US (Houston)
Meeting ID: 920 8136 5511
Password: 490324
Find your local number: https://armltd.zoom.us/u/adYiWaDyys
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.
Hi everyone,
This is just a reminder that the next EBBR biweekly is today at 15:00
GMT. Zoom details are below, and here is today's agenda:
Agenda:
- UEFI EBBR Conformance profile (Jose)
https://bugzilla.tianocore.org/show_bug.cgi?id=3591
- Requirements for measured boot (Ilias)
- Any other business
I'm also keeping track of agenda items on the EBBR wiki which you can
find here:
https://github.com/ARM-software/ebbr/wiki/EBBR-Meetings
Join Zoom Meeting
https://armltd.zoom.us/j/92081365511?pwd=SFZpRitXUEp3Zy9GM0h3UUZ1b1pnUT09
Meeting ID: 920 8136 5511 Password: 490324
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.
All,
Sorry but I have to cancel the call for tomorrow.
See you in two weeks.
Thanks,
Bill
--
Bill Mills
Principal Technical Consultant, Linaro
+1-240-643-0836
TZ: US Eastern
Work Schedule: Tues/Wed/Thur
Hi all,
EBBR Biweekly meetings will resume next week on Monday at 15:00GMT. This
is a new time to line up with the same slot as the Devicetree Evolution
meeting being run by Linaro. Details for joining are below, and can also
be found on the EBBR wiki.
https://github.com/ARM-software/ebbr/wiki/EBBR-Meetings
Here is the agenda so far:
- Update on Arm's SystemReady IR program
- Issue review
- Plans for next iteration of EBBR
- List of potential new requirements
- Other business
As always please email me if you want to add items to the agenda.
---
Topic: EBBR Biweekly
Time: This is a recurring meeting Meet anytime
Join Zoom Meeting
https://armltd.zoom.us/j/92081365511?pwd=SFZpRitXUEp3Zy9GM0h3UUZ1b1pnUT09
Meeting ID: 920 8136 5511
Passcode: 490324
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.
All,
We have our normal DTE call today at the new time of 15 UK.
HOWEVER, the UK has come off daylight savings time while the US and
others have not.
This means that in the US it looks like the old time.
11 AM Eastern
10 AM Central
9 AM Mountain
8 AM Pacific
This is a single week issue that occurs once in the fall and in the once
spring.
It _should_ appear correct on you calendar.
We said we would discuss devicetree lifecycle at the source level.
We will use the second half of the slides from last time:
https://fileserver.linaro.org/s/FqT2JcTxCWStTNY
Thanks,
Bill
--
Bill Mills
Principal Technical Consultant, Linaro
+1-240-643-0836
TZ: US Eastern
Work Schedule: Tues/Wed/Thur
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(a)linaro.org | Skype: ffozog
Hi Tom
Le lun. 25 oct. 2021 à 18:59, Tom Rini <trini(a)konsulko.com> a écrit :
> On Mon, Oct 25, 2021 at 05:41:44PM +0100, Daniel Thompson wrote:
> > 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).
>
> So, this might be an unpopular opinion here, but perhaps the Canonical
> or Linaro lawyers could chime in with some non-binding thoughts?
> Engineers arguing about the law tends to not be productive.
i agree. From my standpoint, there are products on the market that assemble
firmware components such as TF-A , U-Boot and OP-TEE in various ways : so
lawyers have done their job and it is possible.
My question is: can we further characterize the distributed firmware with
regards to parameters described in the checklist?
If there are binary components in the mix, how much a platform owner (in
the checklist sense) can rebuild the open source portion, include the
binaries and redistribute the result?
>
>
> --
> Tom
>
--
François-Frédéric Ozog | *Director Business Development*
T: +33.67221.6485
francois.ozog(a)linaro.org | Skype: ffozog
