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

[Stefano Babic]

Hi Simon,

On 21/11/18 12:13, Simon Goldschmidt wrote:
> 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. 

SWupdate has a modified version of the Webserver (yes, code comes from
Mongoose project) to support streaming. It is a different situation as
libmtd or libubootenv

> 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 :-)

There are big changes. Code was synchronized wit 6.11 version of the
Webserver and old static website was replaced by a responsive Web
application.

> 
>> 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.

Plan depends on other projects, anyway...

> 
> Thanks for your answers!
> 

Best regards,
Stefano

> 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
>> =====================================================================


-- 
=====================================================================
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
=====================================================================