Bug 10518

Summary: swupd compatibility with image-prelink
Product: [Build System, Metadata & Runtime] Other YP Layers Reporter: Patrick Ohly <patrick.ohly>
Component: meta-swupdAssignee: Patrick Ohly <patrick.ohly>
Status: RESOLVED OBSOLETE QA Contact:
Severity: enhancement    
Priority: Undecided CC: brian.avery, elena.reshetova, randy.macleod, richard.purdie
Version: unspecified   
Target Milestone: Future   
Hardware: x86   
OS: Multiple   
Whiteboard:
OS type for building Yocto: --- Type of Regression: ---
Verified: Documentation change: No (bug/feature does not impact docs)
Bug Depends on: 10268    
Bug Blocks:    

Description Patrick Ohly 2016-10-28 06:50:40 UTC 
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!)
Comment 1 Patrick Ohly 2016-10-28 07:01:06 UTC 
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
Comment 2 Elena Reshetova 2016-10-31 07:21:49 UTC 
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.
Comment 3 brian avery 2016-11-03 16:10:15 UTC 
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
Comment 4 Elena Reshetova 2016-11-04 07:08:14 UTC 
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.
Comment 5 Patrick Ohly 2016-11-04 07:30:32 UTC 
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.
Comment 6 brian avery 2016-11-04 18:14:03 UTC 
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.
Comment 7 Richard Purdie 2018-10-11 15:25:59 UTC 
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.