[U-Boot] [swupdate] Re: SWUpdate - U-Boot environment library dependency

[Simon Goldschmidt]

On Wed, Nov 21, 2018 at 10:33 AM Stefano Babic <sbabic at denx.de> wrote:
>
> Hi Wolfgang,
>
> On 21/11/18 09:31, Wolfgang Denk wrote:
> > Dear Simon,
> >
> > In message <90014ca9-64d8-8e38-a6c0-4c06e991c92c at gmail.com> you wrote:
> >>
> >>> However, this approach creates several difficulties:
> >
> > As usual, "difficulties" are made for solving.
> >
> > I mean, none of these are technically challenging in any way.
> >
> >>> * Distros like Debian cannot provide a devel package for SWUpdate like
> >>>    u-boot-dev, since U-Boot has its default environment code compiled
> >>>    board-dependently and Debian needed it board-independent.
> >
> > Thta's fine.
> >
> >>>    If a board-independent libubootenv.a was provided without
> >>>    a specific default environment, the first update process would destroy
> >>>    the U-Boot environment if it had had bad CRC before.
> >>>    (Thanks Stefano for this good point).
> >
> > One possible way to fix this is not to use a compiled in default
> > environment for the fw_env tools (or only use this as a very last
> > resort), but instead provide a configuration option to read the
> > default settings from a file.  In this case the user could provide
> > his own, board specific default environment.
>
> I tried this, but it is very difficult to maintain this in sync,
> specially in projects where the number of developers is > 1 (all
> projects). If the file does not correspond to the linked environment,
> strange behaviors are expected.
>
> Much better will be if u-boot generates in its build process this file.
> It becomes just another artifact like SPL or u-boot.img and we are sure
> that it is in sync.
>
> >
> >>> * If we have a board with U-Boot already preinstalled and want to
> >>>    compile SWUpdate for it, we need the sources of this very U-Boot to
> >>>    get the propper lib. For example in a debian-like build system we had to
> >>>    compile U-Boot again, although it is already installed since we lack
> >>>    a dev package.
> >
> > - Why does building the U-Boot package not also create these
> >   libraries, either directly or as a separate package?
>
> Issue is that there is not a u-boot-dev package
>
> > - What prevents the creation of such a dev package that only builds
> >   the needed lib?
>
> I think Simon wants to prevent to rebuild u-boot.

No, I want to prevent recompiling the u-boot-tools package (fw_setenv)
and Swupdate after changing U-Boot's default environment.

In fact, we are running a Debian-based system and I would like to run
upstream Debian u-boot-tools. And of course running an upstream
swupdate package would be preferred as well.

One way to fix this would be to let fw_setenv somehow write an
environment that doesn't need to know the default environment and is
loaded in a "add" way, not replacing the whole environment as we
normally do on load.

And security wise, I think linking in things as static libs in
Swupdate is not a good decision as you can end up with 2 different
versions of the same sources in your target. I can understand calling
external binaries is not a good solution as well. Using shared libs
would be best. That would mean u-boot-tools fw_setenv would use a
shared library to access the environment and swupdate could use it,
too.

>
> >
> >>> * U-Boot does not provide any default means to install a development
> >>>    library. Thus anything we modify on-top might break with the next
> >>>    version.
> >
> > Why don't you add this, then?  Patches are welcome!
>
> +1
>
> >
> >> Has there been any progress in the SWupdate/fw_setenv integration? I
> >> thought I remember reading something about letting fw_setenv extract the
> >> environment from the U-Boot binary in the target, but I cannot find the
> >> thread. I do think the current situation should be improved, making
> >> fw_setenv independent of the target that is built.
> >
> > To be honest, I think this is not a clever approach.  This whole
> > concept of the compiled in default environment is antediluvian.
>
> Fully agree - I am glad if there will be an improvement.
>
> To be clear: the issue just raises if a board runs with default
> environment. User Space cannot know this environment because it is
> linked in the bootloader - the current way is to link the same
> environment in tools/env (that means, u-boot-fw-tools in OE).
>
> There is no issue at all for boards that are not using default
> environment at all, that means they rely to have always a valid
> environment in flash.
>
> >  It
> > comes from a time where we were booting from parallel NOR flasah (or
> > other boot ROM where you directly started executing code) and where
> > we wanted to make sure that we can read the console baud rate very,
> > very soon.  Today, many boards don't have environment access in the
> > SPL, and nobody complains that these run with a fixed baud rate
> > only.
> >
> > Did anybody ever ask who actually _needs_ this compiled in default
> > environment?

In a secure boot environment, you cannot allow to load the environment
from an untrusted source. We need a default environment in this case.

But there are better ways than compiling it in via C headers, of course!

Simon

>
> Rather, quite all boards....see CONFIG_EXTRA_ENV in include/configs/*
> and the number of patches sent just to fix something in it.
>
> UMHO the default environment should be like an extra image in u-boot,
> like an header added by mkimage, because there is no changes in code and
> behavior. Not to mention that CONFIG_EXTRA_ENV is really error prone
> with the requirement to put each line as a C string with trailing "\0".
>
> > We could provide other, more efficient configurations
> > if we drop a few of the old requirements (which are not met by many
> > recent boards anyway).
>
> All recent boards, specially the one that switched to distro_, use the
> default environment. Thing is that there is no need to add an extra
> environment and the board can boot without any intervention by operator
> (or by factory) simply after flashing the bootloader.
>
> >
> >> And as this thread is on the swupdate group as well: I would prefer
> >> calling an external fw_setenv tool instead of linking in the static
> >> library libubootenv.a...
> >
> > IMO this is just a matter of taste.  Both ways should be possible.
> >
>
> Best regards,
> Stefano Babic
>
> --
> =====================================================================
> DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
> HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
> Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sbabic at denx.de
> =====================================================================