On Thu, Apr 15, 2021 at 10:41:28 -0700, ron minnich wrote:
> HOBS are "bad'.
>
> several reasons.
> 1. They depend on the nature of the C compiler and require use of a keyword
> ("packed") known to be an issue.
> (i.e. there are alignment and padding requirements that not all
> compilers handle the same way for all versions)
/work/git/linux$ git grep packed | wc -l
15305
So I guess LinuxBoot is out too ;)
> In fact, interestingly, a recent OpenTitan document describing best
> practices for binary structs calls out bad practices that
> are used in today's HOBs [they did not know this but I noticed it].
>
> 2. We've seen cases where the components of a HOB change with
> compiler flags
>
> 3. The degree to which they are open is not clear.
>
> It used to be that even the name "HOB" was NDA.
It is mentioned in version 1.2B of the PI specification, released 2010.
www.uefi.org/sites/default/files/resources/PI_Spec_1.2_B.zip
This is the oldest one downloadable from
https://uefi.org/specifications
> For a long time the components were NDA.
I don't recall that far back.
The specifications used to be hidden behind a click-through license.
I think it was 2013 that we managed to get that removed.
> At this moment it's not clear how much is open.
> 4. they are not self-describing; you need to have exact knowledge of their
> binary structure to unpack them.
>
> I'd like to move forward from HOBs to a true self-describing,
> endian-independent, alignment-independent format.
>
> There are lots of these, and many of them are designed in a way that makes
> decoded fast and reliable.
If you want to argue for alternatives on technical or licensing
merits, you are more than welcome to do so.
/
Leif
> ron
>
> On Thu, Apr 15, 2021 at 9:28 AM Ryan O'Leary via groups.io <ryanoleary=
> google....@groups.io> wrote:
>
> > I can add this topic "Sustainable Firmware" to today's OSF call agenda if
> > anyone is interested in discussions.
> >
> > For instructions on joining the call (it's in 30 mins, but repeats every
> > second week): https://www.opencompute.org/projects/open-system-firmware
> >
> > Thanks,
> > Ryan
> >
> > On Thu, Apr 15, 2021 at 8:22 AM ron minnich <rminn...@gmail.com> wrote:
> >
> >> Loic, it is wonderful to have you here. I think in the OCP OSF call today
> >> (to which you are now invited, if you want; let me know -- same applies to
> >> everyone here who's interested in open compute platform open *system*
> >> firmware standard)
> >>
> >> Documenting ABIs is problematical, since not all OSF systems will be
> >> following an existing ABI. That is a box best not opened. Most of the OSF
> >> participants use both UEFI and LinuxBoot, and it's hard to imagine two more
> >> incompatible systems.
> >>
> >> PIcking the size of flash is a hard one too, and it varies a lot
> >> depending on the system, so we felt it best not to bring that in. Intel,
> >> AMD, Power, ARM -- all have widely varying and incompatible issues.
> >>
> >> I wonder if I can interest you (and others) in a workshop I'm trying to
> >> put together for linuxcon dublin end of september.
> >>
> >> LinuxBoot requires a solid kexec, and kexec is not quite there yet. Our
> >> goal is to improve the situation with kexec. An ancillary goal is to get
> >> the various distros to ship images that are "kexec friendly". We did talk
> >> to Mark about all this a few years ago but it was a bit too early. I think
> >> what with systemd starting to look at kexec, now it's time.
> >>
> >> I'd like to get canonical, red hat, and whoever else is interested in a
> >> room and hammer out what we need to do to make kexec solid. As of now it's
> >> too flaky.
> >>
> >> interested? Linux Conf sounds more and more like it will happen, and it
> >> would be good to get people in the room and figure out kexec -- its current
> >> capabilities, how its being used (e.g. Google has deployed LinuxBoot with
> >> kexec at scale), its limits, and how to make distros "kexec friendly"
> >>
> >>
> >>
> >>
> >>
> >> On Thu, Apr 15, 2021 at 1:19 AM Loïc Minier <loic.min...@canonical.com>
> >> wrote:
> >>
> >>> Hi Ron,
> >>>
> >>> Apologies; I clearly hadn't read enough. I just recently joined the
> >>> OCP-OSF project's mailing-list as I wasn't aware of the effort before, and
> >>> had only read the welcome web page. I've now read through the Governance,
> >>> Charter and Transition schedule docs, and also saw the Pilot's draft
> >>> Checklist gdoc and spreadsheet – I can see this overlaps with existing
> >>> sections and topics. (Are there other consolidated docs or efforts you'd
> >>> encourage new contributors to checkout?)
> >>>
> >>> I did see the idea of keys in the Ownership section of the Checklist
> >>> doc. Is there a good place to document supported ABIs (I understand the
> >>> spirit is not to mandate particular interfaces, but it would still make
> >>> sense to document them)?
> >>>
> >>> There are some questions around existing artifacts, would that be the
> >>> right place to document maximum capacity (eg size of flash)?
> >>>
> >>> Thanks,
> >>> - Loïc
> >>>
> >>> On Thu, 15 Apr 2021 at 07:59, ron minnich <rminn...@gmail.com> wrote:
> >>>
> >>>> I do wonder if you have read the OSF doc. That was a lot of work over a
> >>>> near 3 year period, and your doc looks like the very early drafts of that
> >>>> doc. I think it would pay to take a look.
> >>>>
> >>>> On Wed, Apr 14, 2021 at 10:52 PM Loïc Minier <loic.min...@canonical.com>
> >>>> wrote:
> >>>>
> >>>>> 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
> >>>>>
> >>>>>
> >>>
> >>> --
> >>> Loïc Minier
> >>>
> >>> _._,_._,_
> > ------------------------------
> > Groups.io Links:
> >
> > You receive all messages sent to this group.
> >
> > View/Reply Online (#139) <https://OCP-All.groups.io/g/OCP-OSF/message/139>
> > | Reply To Group
> > <ocp-...@ocp-all.groups.io?subject=Re:%20Re%3A%20%5BOCP-OSF%5D%20Firmware%3A%20Sustainability%20vs%20planned%20obsolescence>
> > | Reply To Sender
> > <ryanole...@google.com?subject=Private:%20Re:%20Re%3A%20%5BOCP-OSF%5D%20Firmware%3A%20Sustainability%20vs%20planned%20obsolescence>
> > | Mute This Topic <https://groups.io/mt/81937262/1492462> | New Topic
> > <https://OCP-All.groups.io/g/OCP-OSF/post>
> > Your Subscription <https://OCP-All.groups.io/g/OCP-OSF/editsub/1492462> |
> > Contact
> > 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]
> > _._,_._,_
> >
> >
> _______________________________________________
> boot-architecture mailing list
> boot-architecture@lists.linaro.org
> https://lists.linaro.org/mailman/listinfo/boot-architecture
_______________________________________________
boot-architecture mailing list
boot-architecture@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/boot-architecture
