On 09.04.21 08:59, François Ozog wrote: > > > On Thu, 8 Apr 2021 at 19:34, Heinrich Schuchardt <xypron.g...@gmx.de > <mailto:xypron.g...@gmx.de>> wrote: > > On 4/8/21 10:46 AM, François Ozog wrote: > > On Thu, 8 Apr 2021 at 10:30, Loïc Minier > <loic.min...@canonical.com <mailto: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 <http://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 <mailto: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 > <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. > > Getting a binary now does not mean that you will get a new compatible > binary in two years after a grave security bug has been discovered in > the WiFi firmware or Netflix uses a new encoding scheme. > > So isn't level 2 still on the path to obsolescence? > > I think I had the unconscious idea to have the equivalent of Google > Project Trebble > <https://www.computerworld.com/article/3306443/what-is-project-treble-android-upgrade-fix-explained.html>: > the binary blobs are part of an ABI framework so that the project can > evolve but still get access to old "stuff".
This project is about supporting SoCs for four years and after that comes obsolescence. If you are buying a mid-range phone without the newest SoC, it boils down to the two years obsolescence of Android One phones which is a shame. > There is nothing such as a free meal: blobs are inevitable and we don't > want proliferation of ABI that could slow innovation. > In other words, can we think of a Trebble for firmware that would allow > evolution of the core open source projects and still be able to use old > blobs? > Making a mind experiment with DRAM initialization binary and a TF-A API > change (which happened last year I think on my platform of interest), > that change could have been made in such a way to maintain compatibility > with the old API. > Is it something thinkable in the U-Boot context ? Looking through the U-Boot code I found the "NXP PFE Ethernet driver" for LS1012A boards that uses a firmware blob. Of course using such a blob does not stop us from developing the rest of U-Boot. Yet obsolescence for LS1018A boards will be dictated by the availability of updates for NXP's blob and license conditions. Best regards Heinrich > > >>> > >>> 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 <mailto:francois.o...@linaro.org> | > Skype: ffozog > >>> _______________________________________________ > >>> boot-architecture mailing list > >>> boot-architecture@lists.linaro.org > <mailto:boot-architecture@lists.linaro.org> > >>> https://lists.linaro.org/mailman/listinfo/boot-architecture > <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 <mailto:francois.o...@linaro.org> | Skype: ffozog > > _______________________________________________ boot-architecture mailing list boot-architecture@lists.linaro.org https://lists.linaro.org/mailman/listinfo/boot-architecture
