On Thu, 8 Apr 2021 at 19:34, Heinrich Schuchardt <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> > 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. > > 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". 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 ? 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 | 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
