On Thu, 8 Apr 2021 at 19:53, ron minnich <rminn...@gmail.com> wrote: > You can see how quickly this gets complicated. It is why we tried to > keep the OSF requirements as simple as possible. > > The requirements, in their most basic form, allow owners of systems to > modify firmware, install it, and share it. Open source is not > required. > > But for customers to install firmware is very hard in the x86 world > nowadays. It's impossible on dell and HPE and many other systems, to > name a few. If you modify one bit -- literally one bit -- most modern > servers will fail to boot. > > So going back to your levels: > > level 0: system cannot evolve or be updated. > > Level 0 is where we are today. > > 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). > > This is not really appropriate for OCP, and nobody owning a server > will want OSF if it means capability is lost. I don't think this is > useful for OCP. > > Indeed, here I am just trying to identify what can be the cases
> 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. > > This doesn't really fit the x86 world either. > > Not sure why. Could you elaborate? Here the main system firmware is open source, access to binary elements is facilitated by the providers themselves. So it achieves the sustainability goal. > level 3: all firmware components are open source and can thus be > community maintained. > > The only system on which this works completely today is IBM Power. > > Getting back to Open System Firmware: > > So, to reiterate, Open System Firmware (NOT open source -- open > system) is very simple. > > How can I miss that one!!! > Owners have to be able to modify, install, and share their modified > firmware. > > Modification and installation require that the vendors sell hardware > that allows it. Many x86 vendors can't do this today. > > Sharing is purely a matter for lawyers, and should be possible. > > > > On Thu, Apr 8, 2021 at 10:38 AM 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? > > > > 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 > > >> > > > > > > > > > > > > > > -=-=-=-=-=-=-=-=-=-=-=- > > Groups.io Links: You receive all messages sent to this group. > > View/Reply Online (#129): > https://OCP-All.groups.io/g/OCP-OSF/message/129 > > Mute This Topic: https://groups.io/mt/81937262/1492462 > > Group Owner: ocp-osf+ow...@ocp-all.groups.io > > Unsubscribe: > https://OCP-All.groups.io/g/OCP-OSF/leave/3416184/1492462/253461219/xyzzy > [rminn...@gmail.com] > > -=-=-=-=-=-=-=-=-=-=-=- > > > > > -- 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
