On Wed, Nov 21, 2018 at 12:05 PM Stefano Babic <sba...@denx.de> wrote: > > On 21/11/18 11:21, Simon Goldschmidt wrote: > > On Wed, Nov 21, 2018 at 10:19 AM Stefano Babic <sba...@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: sba...@denx.de > ===================================================================== _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
