On Thu, 8 Apr 2021 at 10:30, Loïc Minier <loic.min...@canonical.com> wrote:
> Hi François-Frédéric, > > Like you, I'm particularly keen to connect the dots between environmental > sustainability and open source software. > > I love your levels, basically recognizing that if the firmware is not > updatable or maintained anymore, or if it can't fulfill its function by > running TAs, the whole system might be rendered obsolete. > > There are two other interesting dimensions I would propose to consider: > - resource requirements of the firmware and payloads such as TAs – the > firmware/system is rendered obsolete because resources available for the > firmware are insufficient, e.g. TAs or binaries grow in size or number or > runtime requirements to the point that the device can't function > I missed that one even though we have a call on this topic today (see on trusted-substrate.org) on how to make TA lifecycle much easier, starting with Secure DRAM size selection by product maker. There is also an ownership transfer discussion that I had with an industrial player that would allow formalization of who can change what "downstream" (here downstream is relative to software chain that starts with firmware and ends with applications) > - architectural requirements – the firmware or its payloads start > requiring recent hardware features or a newer API; this is likely going to > bring some tradeoffs in security as the bar keeps getting higher; this > could connect to your level 2 > > Good point. That said, this should not imply an ACPI HAL like effort by the firmware. In addition, I remember the Panasonic CTO calling for using virtio as a HAL even on non-virtualized environments. Would this be part of the picture? > I'd love to help draft language or with recommendations around this! > > That would be great: what about you share a Google doc and we discuss it here? > Best, > - Loïc Minier > > On Thu, 8 Apr 2021 at 10:12, François Ozog <francois.o...@linaro.org> > wrote: > >> Hi >> >> even though I am not an "ecology activist", sustainability is a topic dear >> to me. And it can translate into firmware world... So I am targeting this >> message to the audience of the two firmware communities I know and hope it >> is okay to do so. >> >> March 2021 was a big date for Open Source Firmware >> <https://www.opencompute.org/projects/open-system-firmware>: that was the >> deadline to get >> >> " >> Owners must be able to change firmware and share it -- including any >> binary >> components -- with other owners. Starting in March, 2021, OCP badging for >> servers will require that systems support OSF. >> " >> >> That's a big step towards sustainability in the OCP world. >> >> More generally, we should have the capacity to characterize firmware >> sustainability for post official firmware End Of Life. >> >> What about the following : >> >> level 0: system cannot evolve or be updated. >> >> level 1: the system can be updated to a bootable minimal functionality >> with >> open community effort.It may lack some features. For instance, you can >> still look at your TV but lose Netflix 4K because the owners (in OCP >> sense) >> cannot get a signed Netflix TA (either updated or not). >> >> level 2: the TAs and other binaries can be made available (signed) to the >> ones maintaining open source firmware projects (TF-A, OP-TEE, U-Boot...). >> For instance, owners (in the OCP sense) can get the updated Netflix TA >> binary (updated or not) and sign it for inclusion. >> >> level 3: all firmware components are open source and can thus be community >> maintained. >> >> I think : >> Level 2 is the right balance between business value and "ecological" goal >> of sustainability. >> Level 3 is not mandatory and not the ultimate goal. >> >> Is this a good way to characterize sustainability? >> How to make at least level 2 happen ? >> >> Cheers >> >> FF >> -- >> François-Frédéric Ozog | *Director Linaro Edge & Fog Computing Group* >> T: +33.67221.6485 >> francois.o...@linaro.org | Skype: ffozog >> _______________________________________________ >> boot-architecture mailing list >> boot-architecture@lists.linaro.org >> https://lists.linaro.org/mailman/listinfo/boot-architecture >> > > > -- > Loïc Minier > -- François-Frédéric Ozog | *Director Linaro Edge & Fog Computing Group* T: +33.67221.6485 francois.o...@linaro.org | Skype: ffozog _______________________________________________ boot-architecture mailing list boot-architecture@lists.linaro.org https://lists.linaro.org/mailman/listinfo/boot-architecture
