[Buildroot] [PATCH] quagga: disable PIE on ARC

[Buildroot] [PATCH] quagga: disable PIE on ARC

[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.

Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
---
 package/quagga/quagga.mk | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/package/quagga/quagga.mk b/package/quagga/quagga.mk
index 756d6e0..ce1d34b 100644
--- a/package/quagga/quagga.mk
+++ b/package/quagga/quagga.mk
@@ -39,4 +39,8 @@ else
 QUAGGA_CONF_OPTS += --disable-vtysh
 endif
 
+ifeq ($(BR2_arc),y)
+QUAGGA_CONF_OPTS += --disable-pie
+endif
+
 $(eval $(autotools-package))
-- 
2.4.3

[Buildroot] [PATCH] quagga: disable PIE on ARC

[Thomas Petazzoni]

Dear Alexey Brodkin,

On Thu,  9 Jul 2015 13:00:11 +0300, Alexey Brodkin wrote:
> 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.
> 
> Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com>
> Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
> ---
>  package/quagga/quagga.mk | 4 ++++
>  1 file changed, 4 insertions(+)

Applied, thanks.

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

[Buildroot] [PATCH] quagga: disable PIE on ARC

[Arnout Vandecappelle]

On 07/09/15 12:00, Alexey Brodkin wrote:
> 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

-- 
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

[Buildroot] [PATCH] quagga: disable PIE on ARC

[Thomas Petazzoni]

Arnout, Alexey,

On Thu, 9 Jul 2015 23:30:14 +0200, Arnout Vandecappelle wrote:
> On 07/09/15 12:00, Alexey Brodkin wrote:
> > 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
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

[Buildroot] [PATCH] quagga: disable PIE on ARC

[Alexey Brodkin]

Hi Thomas, Arnout,

On Fri, 2015-07-10 at 08:44 +0200, Thomas Petazzoni wrote:
> Arnout, Alexey,
> 
> On Thu, 9 Jul 2015 23:30:14 +0200, Arnout Vandecappelle wrote:
> > On 07/09/15 12:00, Alexey Brodkin wrote:
> > > 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.

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

[Buildroot] [PATCH] quagga: disable PIE on ARC

[Arnout Vandecappelle]

On 07/10/15 10:12, Alexey Brodkin wrote:
[snip]

 Thanks for the detailed explanation!

> 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

> 
> 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
> 


-- 
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

[Buildroot] [PATCH] quagga: disable PIE on ARC

[Alexey Brodkin]

Hi Arnout,

On Fri, 2015-07-10 at 12:08 +0200, Arnout Vandecappelle wrote:
> On 07/10/15 10:12, Alexey Brodkin wrote:
> [snip]
> 
>  Thanks for the detailed explanation!
> 
> > 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

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.

>  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

[Buildroot] [PATCH] quagga: disable PIE on ARC

[Arnout Vandecappelle]

On 07/10/15 13:28, Alexey Brodkin wrote:
> Hi Arnout,
> 
> On Fri, 2015-07-10 at 12:08 +0200, Arnout Vandecappelle wrote:
>> On 07/10/15 10:12, Alexey Brodkin wrote:
>> [snip]
>>
>>  Thanks for the detailed explanation!
>>
>>> 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
> 
> 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.

 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



-- 
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

[Buildroot] [PATCH] quagga: disable PIE on ARC

[Thomas Petazzoni]

Dear Arnout Vandecappelle,

On Fri, 10 Jul 2015 14:21:02 +0200, Arnout Vandecappelle wrote:

>  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"

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
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

[Buildroot] [PATCH] quagga: disable PIE on ARC

[Arnout Vandecappelle]

On 07/10/15 15:08, Thomas Petazzoni wrote:
> Dear Arnout Vandecappelle,
> 
> On Fri, 10 Jul 2015 14:21:02 +0200, Arnout Vandecappelle wrote:
> 
>>  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"
> 
> 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


-- 
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