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

Wed Nov 21 11:13:19 UTC 2018

On Wed, Nov 21, 2018 at 12:05 PM Stefano Babic <sbabic at denx.de> wrote:
>
> On 21/11/18 11:21, Simon Goldschmidt wrote:
> > On Wed, Nov 21, 2018 at 10:19 AM Stefano Babic <sbabic at denx.de> wrote:
> >>
> >> Hi Simon,
> >>
> >> On 20/11/18 22:11, Simon Goldschmidt wrote:
> >>> On 04.09.2018 12:30, Andreas Reichel wrote:
> >>>> Hi all,
> >>>>
> >>>> as Stefano Babic was so friendly and pointed out a few things already,
> >>>> we come the following problematic points:
> >>>>
> >>>> For SWupdate to access U-Boot's environment, it uses code from U-Boot.
> >>>> Before 2015, fw_env.c was copied - hence out of version control,
> >>>> afterwards and since then, a lib.a produced by U-Boot has been used
> >>>> and renamed to libubootenv.a to link against.
> >>>>
> >>>> However, this approach creates several difficulties:
> >>>>
> >>>> * 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.
> >>>>    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).
> >>>>
> >>>> * 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.
> >>>>
> >>>> * 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.
> >>>>
> >>>> First proposal by Stefano and me would be to somehow split the default
> >>>> environment from the library to have a board-independent component and
> >>>> board specific data that is passed to U-Boot and SWUpdate somehow.
> >>>>
> >>>> Goal is to factor out U-Boot environment support for other software like
> >>>> SWUpdate and not patching and hacking like its the case with recipes
> >>>> as in
> >>>> openembedded atm.
> >>>
> >>> 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 did some tests, but I have found the way quite fragile. We should need
> >> at least markers to identify begin and end of the environment because
> >> size differs for each board.
> >>
> >>> I do think the current situation should be improved, making
> >>> fw_setenv independent of the target that is built.
> >>
> >> A simple way is to let fw_setenv to get the default env via a parameter
> >> (file), but this is also error prone if u-boot is updated and the file
> >> with default env not.
> >>
> >>>
> >>> 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...
> >>
> >> I do not prefer this - SWUpdate should be as much as possible self
> >> contained (also for security reasons). Linking libubootenv.a is like
> >> linking any other library. The weirdness is just with the default
> >> environment, that should be addressed.
> >
> > For exactly these security reasons, I think it would be better to have
> > the code only once in your target. And this is not only true for the
> > u-boot env lib but also for mtd support and maybe for the webserver.
>
> Webserver ?

Mongoose. Right now, I'm talking about the swupdate 2017.11 branch.
Maybe there are changes regarding webserver since then. I will update
to a newer branch soon (before relase, that is :-)

> I guess you are then about libmtd.a and libubi.a. There is a ticket to
> have a mtd-utils-dev package:
>
>         https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=911821
>
> >
> > If you have the same versions twice, you need to track and fix both
> > versions if there should be issues.
>
> Currently, both mtd-utils and u-boot do not export a library. The only
> user in OE is SWUpdate that has own rules to build it.
>
> Of course, this could be changed (ad it is desired).

Yes, I'm talking about libmtd.a. It's good to know there's a plan to
change that.

Thanks for your answers!

Regards,
Simon

>
> >
> > I know these things are not available as libs right now, even if that
> > would be preferable. Therefore I think calling external binaries could
> > be better.
>
> No.
>
> > And I don't yet understand why calling external binaries
> > would be a security risk, maybe you can explain this to me?
>
> If you check in SWUpdate, you see that code does not call system() at
> all - the only exception is for shell scripts.
>
> The first attack I can imagine (sure that we can find several different
> if we think enough about it) is a leak in your application that let
> change /bin/sh or /usr/bin/fw_setenv on the filesystem. Even if the leak
> is outside SWUpdate, an attacker can use it to avoid an update, run
> malicious code or install something else.
>
> Not only, if SWUpdate remains self-contained, you can jail it in a
> chroot environment - less dependencies SWUpdate has, much better.
>
> 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
> =====================================================================