10518 2016-10-28 06:50:40 +0000 swupd compatibility with image-prelink 2018-10-11 15:25:59 +0000 1 1 7 Build System, Metadata & Runtime Other YP Layers meta-swupd unspecified x86 Multiple RESOLVED OBSOLETE Undecided enhancement Future 10268 1 patrick.ohly patrick.ohly brian.avery elena.reshetova randy.macleod richard.purdie --- --- No (bug/feature does not impact docs) oldest_to_newest 67708 0 patrick.ohly 2016-10-28 06:50:40 +0000 When prelinking is active (for example, due to USER_CLASSES ?= "buildstats image-mklibs image-prelink" as in Ostro OS' local.conf.sample), then binaries that were not recompiled still change during image construction. Prelinking seems to be a bit non-reproducible. For example, configure a build of Ostro OS for qemux86 with BUNDLE_CONTENTS_WORLD="gdb". Build "ostro-image-swupd". Change to BUNDLE_CONTENTS_WORLD="strace". Build again (may need some manual cleanup to work around issues in meta-swupd; I have fixes for those problems). In this example, /usr/lib/liblzma.so.5.2.2 is different in the resulting images (and several more, 226 files in total). I suspect that this is because prelink needs to lay out shared libraries so that they don't overlap when used by any of the binaries available in the system (https://linux.die.net/man/8/prelink). Adding a new binary adds another combination of libs which then changes how libraries need to be laid out. This makes updates larger than they could be. It is unclear whether prelinking works at all in combination with swupd: swupd excludes time stamps from its hashing, so if only the modification time of a file changes, then swupd won't update it on the target. That means there's no guarantee that time stamps of files match the ones in the prelinked image. But prelink depends on time stamps while checking whether the prelinking is still valid. Whether that really breaks prelinking in practice might be worth checking. Overall it seems that it might simpler to just disable prelinking. Depending on the analysis of the this problem, different changes may be needed: - warn (or error?) in meta-swupd when prelinking is active - fix swupd to ensure that time stamps are preserved (major change!) 67710 1 patrick.ohly 2016-10-28 07:01:06 +0000 Elena, can you provide some advice on prelinking (https://linux.die.net/man/8/prelink) and its security implications vs. expected performance increase? See also https://lwn.net/Articles/341244/ for some (very old!) discussion. I'm wondering what the current thinking about this feature is in the security community. See also http://lists.openembedded.org/pipermail/openembedded-core/2015-October/112004.html 67773 2 elena.reshetova 2016-10-31 07:21:49 +0000 So, in short nothing really changed much in prelink world. It is still bad from security point of view since it removes ASLR almost fully. Nowadays prelink comes with -R random option that attempts to randomize load address to be not so horrible from security point of view, but it seems that this address is pretty easy to discoved on running system, so it doesn't add any additional protection in practice. So, conclusion from security point of view: do not use prelink unless absolutely required and be aware of its security implications: mainly return into libc attacks become rather trivial. 67920 3 brian.avery 2016-11-03 16:10:15 +0000 In Bug 10268 I outline the 2 things that introduce the randomization. 1) We *do* use -R by default and this does introduce binary differences. 2) Prelink includes a timestamp for when each library was prelinked. This cannot currently br turned off with an option so this will always introduce binary differences unless we patch prelink. You can also use prelink itself to do binary compares which essentially unlink compare and relink the binaries. More info at https://wiki.yoctoproject.org/wiki/TipsAndTricks/PrelinkSomePointersAndWorkarounds 67962 4 elena.reshetova 2016-11-04 07:08:14 +0000 Default usage of -R flag is certainly better than not using it from security point of view, but it should not be confused with having proper security that ALSR can give in run-time. Just want to make sure everyone understands this. 67964 5 patrick.ohly 2016-11-04 07:30:32 +0000 My conclusion is that supporting prelinking in combination with swupd updates is neither required nor recommended. A device where prelinking is useful enough to justify the disadvantages is likely too small to run swupd. Therefore I intend to resolve this issue here by adding a check in meta-swupd which warns when prelinking is enabled. 67991 6 brian.avery 2016-11-04 18:14:03 +0000 That works for me. If someone really needs it to work with prelinking, the 2 things that need to be changed are straightforward, though, as Elena points out, 1 of them makes it even less secure. (no -R, patch to remove timestamp data which is only used for an on target re prelinking optimization) Basic gain on QEMU system was ~ 10-15% faster. 81812 7 richard.purdie 2018-10-11 15:25:59 +0000 Upstream swupd has changed a lot and integration with the Yocto Project would be tricky and need rework to the layer. Closing this as obsolete since any new integration would need rework and have its own issues.