CONFIG_PKG_ASLR_PIE and CONFIG_USE_MKLIBS are incompatible
Username: Maxim Mikityanskiy
Origin: https://bugs.openwrt.org/index.php?do=details&task_id=1938
I’m building OpenWrt trunk (commit dceee8cc) for Netgear R7800 (though I think, device doesn’t matter here).
It turns out that if both CONFIG_PKG_ASLR_PIE and CONFIG_USE_MKLIBS are turned on, the system renders unusable. In my case, when building with GCC 7, dropbear doesn’t start, and when building with GCC 8, the system doesn’t boot, and the status LED is off.
The culprit is this line:
first find all programs and add them to the mklibs list
find $(STAGING_DIR_ROOT) -type f -perm /100 -exec \
file -r -N -F '' {} + | \
awk ' /executable.*dynamically/ { print $$1 }' > $(TMP_DIR)/mklibs-progs
It should generate the list of executables for mklibs, however, with PIE turned on, most of the executables don’t get into that list. In my config, only fw_printenv gets into the mklibs-progs list. And, because some executables are not on the list, the symbols they need may be stripped off the libraries, rendering these executables unusable.
The reason is that the file command detects PIE executables as shared objects, not as executables. Compare:
With ASLR off: bin/busybox ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), dynamically linked, interpreter /lib/ld-musl-armhf.so.1, with debug_info, not stripped
With ASLR on: bin/busybox ELF 32-bit LSB shared object, ARM, EABI5 version 1 (SYSV), dynamically linked, interpreter /lib/ld-musl-armhf.so.1, with debug_info, not stripped
This one single executable displays the same, independently of ASLR state: usr/sbin/fw_printenv ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), dynamically linked, interpreter /lib/ld-musl-armhf.so.1, stripped
If CONFIG_PKG_ASLR_PIE=n, all executables are detected properly and get into the mklibs-progs list.
A more proper way should be found to detect executables, as the current one skips PIE executables completely and makes the system unusable, because some of the PIE executables can’t start due to missing symbols in libraries.
I’ve chosen the critical severity, because the system doesn’t work if I set those two config options to y, and this combination isn’t something unusual, because many people would like both increased security and smaller size of the firmware.