quagga: disable PIE on ARC
PATCH 1/1 quagga: disable PIE on ARC
Even though ARC gcc understands "-pie" option and attempts to generate PIE binaries as of today PIE is not really supported for user-space applications.
So we disable PIE detection if building for ARC.
That fixes http://autobuild.buildroot.net/results/ca0/ca0b1e271f29d7639b6a6e895472a35e2c1d8aba
and also prevents execution of non-supported PIE binary in runtime.
--- package/quagga/quagga.mk | 4 ++++ 1 file changed, 4 insertions(+)
package/quagga/quagga.mk +4 -0
@@ -39,4 +39,8 @@ else QUAGGA_CONF_OPTS += --disable-vtysh endif +ifeq ($(BR2_arc),y) +QUAGGA_CONF_OPTS += --disable-pie +endif + $(eval $(autotools-package))
Signature · 1 line
2.4.3
Thomas Petazzoni
AppliedPATCH 1/1 quagga: disable PIE on ARC
Dear Alexey Brodkin,
Quoted 8 lines · Alexey Brodkin
Even though ARC gcc understands "-pie" option and attempts to generate PIE binaries as of today PIE is not really supported for user-space applications.
So we disable PIE detection if building for ARC.
That fixes http://autobuild.buildroot.net/results/ca0/ca0b1e271f29d7639b6a6e895472a35e2c1d8aba
and also prevents execution of non-supported PIE binary in runtime.
Quoted 5 lines
Signed-off-by Alexey Brodkin <[email protected]>Cc Thomas Petazzoni <[email protected]>--- package/quagga/quagga.mk | 4 ++++ 1 file changed, 4 insertions(+)
Applied, thanks.
Thomas
Signature · 3 lines
Thomas Petazzoni, CTO, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com
PATCH 1/1 quagga: disable PIE on ARC
In reply to Alexey BrodkinQuoted 3 lines · Alexey Brodkin
Even though ARC gcc understands "-pie" option and attempts to generate PIE binaries as of today PIE is not really supported for user-space applications.
Wouldn't it be better then if we would patch gcc to remove the -pie option?
That removes all these special cases in one fell swoop, and is much easier to un-disable once PIE _is_ supported for ARC gcc.
Regards,
Arnout
Signature · 6 lines
Arnout Vandecappelle arnout at mind be Senior Embedded Software Architect +32-16-286500 Essensium/Mind http://www.mind.be G.Geenslaan 9, 3001 Leuven, Belgium BE 872 984 063 RPR Leuven LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle GPG fingerprint: 7493 020B C7E3 8618 8DEC 222C 82EB F404 F9AC 0DDF
PATCH 1/1 quagga: disable PIE on ARC
Arnout, Alexey,
Quoted 8 lines · Arnout Vandecappelle
Quoted 3 lines · Alexey Brodkin
Even though ARC gcc understands "-pie" option and attempts to generate PIE binaries as of today PIE is not really supported for user-space applications.
Wouldn't it be better then if we would patch gcc to remove the -pie option?
That removes all these special cases in one fell swoop, and is much easier to un-disable once PIE _is_ supported for ARC gcc.
It would indeed be a lot better.
Best regards,
Thomas
Signature · 3 lines
Thomas Petazzoni, CTO, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com
PATCH 1/1 quagga: disable PIE on ARC
Hi Thomas, Arnout,
Quoted 8 lines · Thomas Petazzoni
Arnout, Alexey,
Quoted 5 lines · Arnout Vandecappelle
Quoted 3 lines · Alexey Brodkin
Even though ARC gcc understands "-pie" option and attempts to generate PIE binaries as of today PIE is not really supported for user-space applications.
Quoted 5 lines
Quoted 3 lines
Wouldn't it be better then if we would patch gcc to remove the -pie option?
That removes all these special cases in one fell swoop, and is much easier to un-disable once PIE _is_ supported for ARC gcc.It would indeed be a lot better.
I would agree with that proposal but... TL;DR below :)
Actually at the moment the only real "user" of PIE (in case of ARC) is U-Boot. U-Boot (by its generic design which is architecture independent) does "self-relocation" on early boot.
Scenario is simple.
We assume that U-Boot executable is located in ROM after power-up and what's more important has access to very limited amount of RAM.
For example on Intel machines U-Boot uses locked cache as pre-relocation RAM. Other examples could be on-chip RAM etc.
So what happens U-Boot does very-very basic initialization including say DDR init and then U-Boot copies itself in DDR (in the very end of available memory so it may then load something useful in the beginning of DDR for example Linux kernel or other executable).
But to have an ability to execute relocated/moved code and access data that was also moved it's required to fixup locations of functions and data units that are accessed directly (i.e. by its address compared to relative offset from current location).
Note that U-Boot copies all sections be it .data, .text, .rel etc. except .bss which is supposed to be used only after relocation and so its area just gets zeroed during "relocation".
And what happens U-Boot is linked with "-pae" which leads to a fact that executable contains a special section called usually .rel or .rela where resides information about all directly addressed units.
During relocation U-Boot once all required sections were copied from flash/ROM to DDR reads data from .rel/.rela updates all directly used addresses (by simple addition of offset between address in flash/ROM and new location in DDR).
What is important PIC (Position-Independent Code) is not enough here because it only cares about code but not data. While PIE (Position-Independent Executable) cares about both code and data.
Now we have U-Boot for ARC and it could be built from any recent upstream U-Boot release. And we want people to have ability to build U-Boot with Buildroot.
But as we know Buildroot builds only one toolchain for all purposes. Even for building Linux kernel or U-Boot while those are bare-metal executables compared to user-space apps that are normally built by *libc-toolchain.
In other words if we disable PIE in Buildroot's toolchain there will be no way to build U-Boot for ARC. And that's not what we want.
Note that U-Boot needs PIE not only on ARC but on x86, ARM and MIPS. So that's not unique "feature" or ARC. Some arches still use PIC in U-Boot but that causes problems here and there, requiring to patch offsets manually in each and every driver etc instead of using gcc, grep for CONFIG_NEEDS_MANUAL_RELOC if of any interest :)
Hopefully my explanation makes some sense.
If you guys have any thought on how to solve that problem better please shout.
-Alexey
PATCH 1/1 quagga: disable PIE on ARC
On 07/10/15 10:12, Alexey Brodkin wrote:
[snip]
Thanks for the detailed explanation!
Quoted 2 lines
In other words if we disable PIE in Buildroot's toolchain there will be no way to build U-Boot for ARC. And that's not what we want.
It's probably getting complicated, but we could add either another option or an
environment variable to enable PIE again. E.g. if it's an envrionment variable, then we can do for packages that we know do *not* break with ARC-PIE:
ifneq ($(BR2_arc),)UBOOT_MAKE_ENV += GCC_REALLY_SUPPORT_PIE=1
endif
(and of course make sure that UBOOT_MAKE_ENV is used, which is currently not the case in uboot.mk).
Question is: is that more complicated that the current per-package workarounds
or not?
Regards,
Arnout
Quoted 14 lines
Note that U-Boot needs PIE not only on ARC but on x86, ARM and MIPS. So that's not unique "feature" or ARC. Some arches still use PIC in U-Boot but that causes problems here and there, requiring to patch offsets manually in each and every driver etc instead of using gcc, grep for
CONFIG_NEEDS_MANUAL_RELOCif of any interest :)Hopefully my explanation makes some sense.
If you guys have any thought on how to solve that problem better please shout.
-Alexey
Signature · 6 lines
Arnout Vandecappelle arnout at mind be Senior Embedded Software Architect +32-16-286500 Essensium/Mind http://www.mind.be G.Geenslaan 9, 3001 Leuven, Belgium BE 872 984 063 RPR Leuven LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle GPG fingerprint: 7493 020B C7E3 8618 8DEC 222C 82EB F404 F9AC 0DDF
PATCH 1/1 quagga: disable PIE on ARC
Hi Arnout,
Quoted 8 lines · Arnout Vandecappelle
On 07/10/15 10:12, Alexey Brodkin wrote:
[snip]Thanks for the detailed explanation!
Quoted 2 lines
In other words if we disable PIE in Buildroot's toolchain there will be no way to build U-Boot for ARC. And that's not what we want.
Quoted 7 lines
It's probably getting complicated, but we could add either another option or an
environment variable to enable PIE again. E.g. if it's an envrionment variable, then we can do for packages that we know do *not* break with ARC-PIE:ifneq ($(BR2_arc),)
UBOOT_MAKE_ENV+= GCC_REALLY_SUPPORT_PIE=1
endif
We may add that new definition but the question is how it is supposed to work? My understanding is once we have gcc built with PIE support it [gcc] will happily accept "-pie" flag in command-line and will generate output accordingly.
And we don't know which software packages use PIE or may use (depending on autoconf detection).
So the only real solution is to make sure GCC doesn't even accept "-pie" option. I assume it's possible to do while we're building GCC itself. But if we do this we'll a toolchain that cannot generate PIE executables and there will be no way to build U-Boot any longer.
Probably I'm missing something here and you guys may correct me.
Quoted 2 lines
Question is: is that more complicated that the current per-package workarounds
or not?
I really don't like that approach with fixing every package that may use PIE but since I don't see any other solution (until PIE gets fixed in both ARc GCC and runtime software) I have to go that way.
-Alexey
PATCH 1/1 quagga: disable PIE on ARC
Quoted 15 lines · Alexey Brodkin
Hi Arnout,
Quoted 12 lines · Arnout Vandecappelle
On 07/10/15 10:12, Alexey Brodkin wrote:
[snip]Thanks for the detailed explanation!
Quoted 2 lines
In other words if we disable PIE in Buildroot's toolchain there will be no way to build U-Boot for ARC. And that's not what we want.
It's probably getting complicated, but we could add either another option or an
environment variable to enable PIE again. E.g. if it's an envrionment variable, then we can do for packages that we know do *not* break with ARC-PIE:
Quoted 7 lines
Quoted 3 lines
ifneq ($(BR2_arc),)
UBOOT_MAKE_ENV+= GCC_REALLY_SUPPORT_PIE=1
endifWe may add that new definition but the question is how it is supposed to work? My understanding is once we have gcc built with PIE support it [gcc] will happily accept "-pie" flag in command-line and will generate output accordingly.
What I mean is that we patch gcc and only support the pie option if that magic
environment variable is set.
But looking at the source, that's not going to be easy since the whole command
line parsing is abstracted in a way that makes it difficult to hack something like that.
Perhaps another solution is that we disable -pie in the spec file, and pass an
alternative spec file which does have pie support in U-Boot:
UBOOT_MAKE_OPTS += \ CC="$(TARGET_CC) -specs=path-to-specfile-with-pie"
Regards,
Arnout
Signature · 6 lines
Arnout Vandecappelle arnout at mind be Senior Embedded Software Architect +32-16-286500 Essensium/Mind http://www.mind.be G.Geenslaan 9, 3001 Leuven, Belgium BE 872 984 063 RPR Leuven LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle GPG fingerprint: 7493 020B C7E3 8618 8DEC 222C 82EB F404 F9AC 0DDF
PATCH 1/1 quagga: disable PIE on ARC
Dear Arnout Vandecappelle,
Quoted 7 lines · Arnout Vandecappelle
What I mean is that we patch gcc and only support the pie option if that magic
environment variable is set.But looking at the source, that's not going to be easy since the whole command
line parsing is abstracted in a way that makes it difficult to hack something like that.
Quoted 5 lines
Perhaps another solution is that we disable -pie in the spec file, and pass an
alternative spec file which does have pie support in U-Boot:UBOOT_MAKE_OPTS += \ CC="$(TARGET_CC) -specs=path-to-specfile-with-pie"
In the end, this seems quite complicated. Not that many packages try to build their executables as PIE, so maybe handling that on a per-package basis is easier / less hacky.
Thomas
Signature · 3 lines
Thomas Petazzoni, CTO, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com
PATCH 1/1 quagga: disable PIE on ARC
Quoted 14 lines · Thomas Petazzoni
Dear Arnout Vandecappelle,
Quoted 10 lines · Arnout Vandecappelle
What I mean is that we patch gcc and only support the pie option if that magic
environment variable is set.But looking at the source, that's not going to be easy since the whole command
line parsing is abstracted in a way that makes it difficult to hack something like that.Perhaps another solution is that we disable -pie in the spec file, and pass an
alternative spec file which does have pie support in U-Boot:
Quoted 6 lines
Quoted 2 lines
UBOOT_MAKE_OPTS += \ CC="$(TARGET_CC) -specs=path-to-specfile-with-pie"In the end, this seems quite complicated. Not that many packages try to build their executables as PIE, so maybe handling that on a per-package basis is easier / less hacky.
Less hacky for sure.
And at this point probably also easier, since probably most of them have
already been handled.
Regards,
Arnout
Signature · 6 lines
Arnout Vandecappelle arnout at mind be Senior Embedded Software Architect +32-16-286500 Essensium/Mind http://www.mind.be G.Geenslaan 9, 3001 Leuven, Belgium BE 872 984 063 RPR Leuven LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle GPG fingerprint: 7493 020B C7E3 8618 8DEC 222C 82EB F404 F9AC 0DDF