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?
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
_______________________________________________
boot-architecture mailing list
boot-architecture@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/boot-architecture
