On 21/11/18 11:21, Simon Goldschmidt wrote:
On Wed, Nov 21, 2018 at 10:19 AM Stefano Babic sbabic@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 ?
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).
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