On Fri, 9 Apr 2021 at 13:32, Heinrich Schuchardt xypron.glpk@gmx.de wrote:
On 09.04.21 08:59, François Ozog wrote:
On Thu, 8 Apr 2021 at 19:34, Heinrich Schuchardt <xypron.glpk@gmx.de mailto:xypron.glpk@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.minier@canonical.com <mailto:loic.minier@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 isnot
>> 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 aroundthis!
>> >> 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.ozog@linaro.org <mailto:francois.ozog@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 -- includingany
>>> 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 characterizefirmware
>>> 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 (inOCP
>>> 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...
: 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.ozog@linaro.org <mailto:francois.ozog@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.ozog@linaro.org <mailto:francois.ozog@linaro.org | Skype: ffozog