Hi! Sorry for the late reply, here's a draft the concepts from this thread and link them to sustainability levels: https://docs.google.com/document/d/1cihVQPf377c2W5ElT4ouvVx6VpDTE6mrAIbakKCEW7Y/edit?usp=sharing (doc open for comments / suggestions from anyone, ping me if you need write access)
Best, - Loïc Minier On Fri, 9 Apr 2021 at 13:45, François Ozog <francois.o...@linaro.org> wrote: > > > On Fri, 9 Apr 2021 at 13:32, Heinrich Schuchardt <xypron.g...@gmx.de> > wrote: > >> 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. >> >> In a Trebble for Android world: there is an immutable ABI for ethernet > driver (the most complex to accept has been on the GPU side). So you can > update the entire system and still use an old blob. > In a Trebble ofr U-Boot, we would define a similar immutable ABI for > ethernet. > Should NXP have compatible licensing conditions, some systems could be > sustainability "level 2". > (The goal is not to have all products be level 2 or 3, the goal is to > understand what is possible with a particular product, and may be make a > buying decision) > >> 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 >> > >> > >> >> > > -- > François-Frédéric Ozog | *Director Linaro Edge & Fog Computing Group* > T: +33.67221.6485 > francois.o...@linaro.org | Skype: ffozog > > -- Loïc Minier _______________________________________________ boot-architecture mailing list boot-architecture@lists.linaro.org https://lists.linaro.org/mailman/listinfo/boot-architecture
