commit: https://git.buildroot.net/buildroot/commit/?id=e7dd5be8db6c19b918b9e1f11190ca431dd90894
branch: https://git.buildroot.net/buildroot/commit/?id=refs/heads/2021.02.x
Recently in Buildroot the option BR2_PIC_PIE has been enabled by default along
with other hardening features [1]. Since then the nios2 defconfig
qemu_nios2_10m50_defconfig is failing to boot due to a segfault in init program:
Run /init as init process
with arguments:
/init
with environment:
HOME=/
TERM=linux
Failed to execute /init (error -12)
See Buildroot build log and Qemu runtime test log in build artifacts [2].
Analyzing one of the binary with strace show that the problem occur
very early when starting the new process:
# strace ./busybox
execve("./busybox", ["./busybox"], 0x7f91ce90 /* 10 vars */) = -1 ENOMEM
(Cannot allocate memory)
+++ killed by SIGSEGV +++
Several binutils/glibc/gcc version has been tested without any success.
The issue has been reported to the glibc mailing list but it can be a linker
or kernel bug [3].
For the Buildroot 2021.05 release, disable BR2_PIC_PIE until the problem is
found and fixed.
Fixes:
https://gitlab.com/buildroot.org/buildroot/-/jobs/1285145889
[1] https://git.buildroot.net/buildroot/commit/?id=810ba387bec3c5b6904e8893fb4cb6f9d3717466
[2] https://gitlab.com/buildroot.org/buildroot/-/jobs/1285145889
[3] https://sourceware.org/pipermail/libc-alpha/2021-May/126912.html
Signed-off-by: Romain Naour <redacted>
Cc: Yann E. MORIN <redacted>
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <redacted>
(cherry picked from commit 6b4b63a571d7e12042d661852f034ff413ec25a7)
[Peter: backport to 2021.02.x to stop users from manually enabling BR2_PIC_PIE]
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
---
Config.in | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/Config.in b/Config.in
index e35a78fb71..18a90b3f62 100644
--- a/Config.in
+++ b/Config.in
@@ -715,6 +715,8 @@ comment "Security Hardening Options"
config BR2_PIC_PIE
bool "Build code with PIC/PIE"
+ # Nios2 toolchains produce non working binaries with -fPIC
+ depends on !BR2_nios2
depends on BR2_SHARED_LIBS
depends on BR2_TOOLCHAIN_SUPPORTS_PIE
help
@@ -722,6 +724,7 @@ config BR2_PIC_PIE
Position-Independent Executables (PIE).
comment "PIC/PIE needs a toolchain w/ PIE"
+ depends on !BR2_nios2
depends on BR2_SHARED_LIBS
depends on !BR2_TOOLCHAIN_SUPPORTS_PIE
@@ -808,6 +811,7 @@ config BR2_RELRO_PARTIAL
config BR2_RELRO_FULL
bool "Full"
+ depends on !BR2_nios2 # BR2_PIC_PIE
depends on BR2_TOOLCHAIN_SUPPORTS_PIE
select BR2_PIC_PIE
help
@@ -816,6 +820,7 @@ config BR2_RELRO_FULL
program loading, i.e every time an executable is started.
comment "RELRO Full needs a toolchain w/ PIE"
+ depends on !BR2_nios2
depends on !BR2_TOOLCHAIN_SUPPORTS_PIE
endchoice
Recently in Buildroot the option BR2_PIC_PIE has been enabled by default along
with other hardening features [1]. Since then the nios2 defconfig
qemu_nios2_10m50_defconfig is failing to boot due to a segfault in init program:
You probably just don't want to enable PIE for nios2 at all.
Even switch statement jump tables are problematic in shared objects.
(I think the table has to go in .code to ensure it is <16k from
the instructions that use it.)
The change to gcc certainly broke our use where the code is 'pure'.
We only run a few kB of code.
It is worth remembering that the nios2 is a simple in-order cpu
built from FPGA logic elements.
Getting one to run@much over 100MHz is hard.
We do use them for embedded code loops, I really can't imagine
running Linux on one - probably too slow to be really useful.
After all, if you need to run Linux on an fpga there are plently
with a small ARM core 'in the corner'.
David
-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)
quoted
quoted
quoted
quoted
"David" == David Laight [off-list ref] writes:
Hi,
>> Recently in Buildroot the option BR2_PIC_PIE has been enabled by default along
>> with other hardening features [1]. Since then the nios2 defconfig
>> qemu_nios2_10m50_defconfig is failing to boot due to a segfault in init program:
> You probably just don't want to enable PIE for nios2 at all.
Notice that this commit was about disallowing PIE for nios2.
> Even switch statement jump tables are problematic in shared objects.
> (I think the table has to go in .code to ensure it is <16k from
> the instructions that use it.)
> The change to gcc certainly broke our use where the code is 'pure'.
> We only run a few kB of code.
> It is worth remembering that the nios2 is a simple in-order cpu
> built from FPGA logic elements.
> Getting one to run at much over 100MHz is hard.
> We do use them for embedded code loops, I really can't imagine
> running Linux on one - probably too slow to be really useful.
> After all, if you need to run Linux on an fpga there are plently
> with a small ARM core 'in the corner'.
Yes, I also cannot recommend people using nios2 (or microblaze for that
matter) for Linux systems.
--
Bye, Peter Korsgaard
From: Peter Korsgaard
Sent: 10 June 2021 16:06
quoted
quoted
quoted
quoted
quoted
"David" == David Laight [off-list ref] writes:
Hi,
>> Recently in Buildroot the option BR2_PIC_PIE has been enabled by default along
>> with other hardening features [1]. Since then the nios2 defconfig
>> qemu_nios2_10m50_defconfig is failing to boot due to a segfault in init program:
> You probably just don't want to enable PIE for nios2 at all.
Notice that this commit was about disallowing PIE for nios2.
Indeed, but maybe you want a stronger note that you really
don't want any of the 'hardening' features on such a slow processor.
...
Yes, I also cannot recommend people using nios2 (or microblaze for that
matter) for Linux systems.
Never mind Linux, I don't think I'd even run VxWorks.
We have about 4 instructions to set up %sp and then jump
straight to the C code loop.
No os, no libc, no nothing, just a code loop.
The one that does 64 channels of 64k hdlc (for SS7) running
at 62.5MHz doesn't ever write to the stack.
I did 'cheat', there are some custom instructions for the
bitstuffing and abort/flag detection.
David
-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)