Hi Simon, On 21/11/18 12:13, Simon Goldschmidt wrote: > 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.
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: sba...@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: sba...@denx.de ===================================================================== _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
