Open Stephen-Seo opened 2 years ago
Looking at the build log you provided, I guess it's caused by our commit Revert "mm: revert x86_64 and arm64 ELF_ET_DYN_BASE base changes".
I tested a basically no-op program:
int main() {
return 0;
}
If compiled with gcc -fsanitize=address -o test noop_program.c
and run, then it will crash. Without the -fsanitize=address
it runs fine.
==4336==Shadow memory range interleaves with an existing memory mapping. ASan cannot proceed correctly. ABORTING.
==4336==ASan shadow was supposed to be located in the [0x00007fff7000-0x10007fff7fff] range.
==4336==This might be related to ELF_ET_DYN_BASE change in Linux 4.12.
==4336==See https://github.com/google/sanitizers/issues/856 for possible workarounds.
==4336==Process memory map follows:
0x045824f83000-0x045824f84000 /home/stephen/temp/test
0x045824f84000-0x045824f85000 /home/stephen/temp/test
0x045824f85000-0x045824f86000 /home/stephen/temp/test
0x045824f86000-0x045824f87000 /home/stephen/temp/test
0x045824f87000-0x045824f88000 /home/stephen/temp/test
0x6d57a2700000-0x6d57a2800000
0x6d57a2900000-0x6d57a2a00000
0x6d57a2b00000-0x6d57a2c00000
0x6d57a2d00000-0x6d57a2e00000
0x6d57a2f00000-0x6d57a3000000
0x6d57a3012000-0x6d57a33a5000
0x6d57a33a5000-0x6d57a33a8000 /usr/lib/libgcc_s.so.1
0x6d57a33a8000-0x6d57a33bf000 /usr/lib/libgcc_s.so.1
0x6d57a33bf000-0x6d57a33c3000 /usr/lib/libgcc_s.so.1
0x6d57a33c3000-0x6d57a33c4000 /usr/lib/libgcc_s.so.1
0x6d57a33c4000-0x6d57a33c5000 /usr/lib/libgcc_s.so.1
0x6d57a33c5000-0x6d57a33d5000 /usr/lib/libm.so.6
0x6d57a33d5000-0x6d57a344e000 /usr/lib/libm.so.6
0x6d57a344e000-0x6d57a34aa000 /usr/lib/libm.so.6
0x6d57a34aa000-0x6d57a34ab000 /usr/lib/libm.so.6
0x6d57a34ab000-0x6d57a34ac000 /usr/lib/libm.so.6
0x6d57a34ac000-0x6d57a3546000 /usr/lib/libstdc++.so.6.0.30
0x6d57a3546000-0x6d57a365d000 /usr/lib/libstdc++.so.6.0.30
0x6d57a365d000-0x6d57a36d4000 /usr/lib/libstdc++.so.6.0.30
0x6d57a36d4000-0x6d57a36e1000 /usr/lib/libstdc++.so.6.0.30
0x6d57a36e1000-0x6d57a36e2000 /usr/lib/libstdc++.so.6.0.30
0x6d57a36e2000-0x6d57a36e5000
0x6d57a36e5000-0x6d57a3711000 /usr/lib/libc.so.6
0x6d57a3711000-0x6d57a3889000 /usr/lib/libc.so.6
0x6d57a3889000-0x6d57a38dd000 /usr/lib/libc.so.6
0x6d57a38dd000-0x6d57a38de000 /usr/lib/libc.so.6
0x6d57a38de000-0x6d57a38e1000 /usr/lib/libc.so.6
0x6d57a38e1000-0x6d57a38e4000 /usr/lib/libc.so.6
0x6d57a38e4000-0x6d57a38f1000
0x6d57a38f1000-0x6d57a3915000 /usr/lib/libasan.so.8.0.0
0x6d57a3915000-0x6d57a39fe000 /usr/lib/libasan.so.8.0.0
0x6d57a39fe000-0x6d57a3a33000 /usr/lib/libasan.so.8.0.0
0x6d57a3a33000-0x6d57a3a37000 /usr/lib/libasan.so.8.0.0
0x6d57a3a37000-0x6d57a3a3a000 /usr/lib/libasan.so.8.0.0
0x6d57a3a3a000-0x6d57a3fa0000
0x6d57a3fbc000-0x6d57a3fd7000
0x6d57a3fd7000-0x6d57a3fdb000 [vvar]
0x6d57a3fdb000-0x6d57a3fdd000 [vdso]
0x6d57a3fdd000-0x6d57a3fdf000 /usr/lib/ld-linux-x86-64.so.2
0x6d57a3fdf000-0x6d57a4006000 /usr/lib/ld-linux-x86-64.so.2
0x6d57a4006000-0x6d57a4011000 /usr/lib/ld-linux-x86-64.so.2
0x6d57a4011000-0x6d57a4012000
0x6d57a4012000-0x6d57a4014000 /usr/lib/ld-linux-x86-64.so.2
0x6d57a4014000-0x6d57a4016000 /usr/lib/ld-linux-x86-64.so.2
0x716d528bc000-0x716d528de000 [stack]
==4336==End of process memory map.
I think this may be expected as the issues with asan were the reason behind reverting the patch.
This is mentioned in revert description
There is a tracking issue on KSPP about working around the problem but no progress so far.
@Bernhard40 thanks for filling in the info here.
The mentioned revert and the reason related to ASan expectations/limitations is indeed the culprit why this doesn't work with linux-hardened. This unfortunately is expected until upstream finds a solution to this issue.
Bug can be reproduced by building the AUR package
blender-git
with the following patch applied to its PKGBUILD (to make it build in Debug mode): https://gist.github.com/Stephen-Seo/88b7453a47e38f7cecf26dfde43ecf58The following appears in the build log at error: https://gist.github.com/Stephen-Seo/897d12b778ab44c304ae535a23635871
The bug can be reproduced without rebuilding by going into "$srcdir/build/bin/" and running the "datatoc" binary with no arguments within that directory. The source of this file is located at "$srcdir/blender/source/blender/datatoc/datattoc.c".
The
datatoc
binary builds and runs fine on stock "linux" kernel, but not on "linux-hardened", even if the binary was built when booted into the stock "linux" kernel.EDIT: The relevant entry in "compile_commands.json" generated by cmake is:
(one may have to change some directory paths to get this to work. Also, this program appears to have no dependencies, so one should be able to compile it directly into an executable instead of an object file.)