diff mbox

[3/3] efi/libstub: arm64: set -fpie when building the EFI stub

Message ID 20170518090953.32628-4-ard.biesheuvel@linaro.org (mailing list archive)
State New, archived
Headers show

Commit Message

Ard Biesheuvel May 18, 2017, 9:09 a.m. UTC
Clang may emit absolute symbol references when building in non-PIC mode,
even when using the default 'small' code model, which is already mostly
position independent to begin with, due to its use of adrp/add pairs
that have a relative range of +/- 4 GB. The remedy is to pass the -fpie
flag, which can be done safely now that the code has been updated to avoid
GOT indirections (which may be emitted due to the compiler assuming that
the PIC/PIE code may end up in a shared library that is subject to ELF
symbol preemption)

Passing -fpie when building code that needs to execute at an a priori
unknown offset is arguably an improvement in any case, and given that
the recent visibility changes allow the PIC build to pass with GCC as
well, let's add -fpie for all arm64 builds rather than only for Clang.

Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
---
 drivers/firmware/efi/libstub/Makefile | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

Comments

Matthias Kaehlcke June 8, 2017, 7:08 p.m. UTC | #1
El Thu, May 18, 2017 at 10:09:53AM +0100 Ard Biesheuvel ha dit:

> Clang may emit absolute symbol references when building in non-PIC mode,
> even when using the default 'small' code model, which is already mostly
> position independent to begin with, due to its use of adrp/add pairs
> that have a relative range of +/- 4 GB. The remedy is to pass the -fpie
> flag, which can be done safely now that the code has been updated to avoid
> GOT indirections (which may be emitted due to the compiler assuming that
> the PIC/PIE code may end up in a shared library that is subject to ELF
> symbol preemption)
> 
> Passing -fpie when building code that needs to execute at an a priori
> unknown offset is arguably an improvement in any case, and given that
> the recent visibility changes allow the PIC build to pass with GCC as
> well, let's add -fpie for all arm64 builds rather than only for Clang.
> 
> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>

Tested-by: Matthias Kaehlcke <mka@chromium.org>
Ard Biesheuvel June 8, 2017, 7:18 p.m. UTC | #2
On 8 June 2017 at 19:08, Matthias Kaehlcke <mka@chromium.org> wrote:
> El Thu, May 18, 2017 at 10:09:53AM +0100 Ard Biesheuvel ha dit:
>
>> Clang may emit absolute symbol references when building in non-PIC mode,
>> even when using the default 'small' code model, which is already mostly
>> position independent to begin with, due to its use of adrp/add pairs
>> that have a relative range of +/- 4 GB. The remedy is to pass the -fpie
>> flag, which can be done safely now that the code has been updated to avoid
>> GOT indirections (which may be emitted due to the compiler assuming that
>> the PIC/PIE code may end up in a shared library that is subject to ELF
>> symbol preemption)
>>
>> Passing -fpie when building code that needs to execute at an a priori
>> unknown offset is arguably an improvement in any case, and given that
>> the recent visibility changes allow the PIC build to pass with GCC as
>> well, let's add -fpie for all arm64 builds rather than only for Clang.
>>
>> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
>
> Tested-by: Matthias Kaehlcke <mka@chromium.org>

Thanks Matthias.

For the record, did you test only with Clang?
Matthias Kaehlcke June 8, 2017, 7:44 p.m. UTC | #3
El Thu, Jun 08, 2017 at 07:18:36PM +0000 Ard Biesheuvel ha dit:

> On 8 June 2017 at 19:08, Matthias Kaehlcke <mka@chromium.org> wrote:
> > El Thu, May 18, 2017 at 10:09:53AM +0100 Ard Biesheuvel ha dit:
> >
> >> Clang may emit absolute symbol references when building in non-PIC mode,
> >> even when using the default 'small' code model, which is already mostly
> >> position independent to begin with, due to its use of adrp/add pairs
> >> that have a relative range of +/- 4 GB. The remedy is to pass the -fpie
> >> flag, which can be done safely now that the code has been updated to avoid
> >> GOT indirections (which may be emitted due to the compiler assuming that
> >> the PIC/PIE code may end up in a shared library that is subject to ELF
> >> symbol preemption)
> >>
> >> Passing -fpie when building code that needs to execute at an a priori
> >> unknown offset is arguably an improvement in any case, and given that
> >> the recent visibility changes allow the PIC build to pass with GCC as
> >> well, let's add -fpie for all arm64 builds rather than only for Clang.
> >>
> >> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
> >
> > Tested-by: Matthias Kaehlcke <mka@chromium.org>
> 
> Thanks Matthias.
> 
> For the record, did you test only with Clang?

With both gcc and clang. Booting has only been tested with an older
kernel (v3.18), I suppose it shouldn't make a difference.
diff mbox

Patch

diff --git a/drivers/firmware/efi/libstub/Makefile b/drivers/firmware/efi/libstub/Makefile
index f7425960f6a5..e078390ba477 100644
--- a/drivers/firmware/efi/libstub/Makefile
+++ b/drivers/firmware/efi/libstub/Makefile
@@ -10,7 +10,7 @@  cflags-$(CONFIG_X86)		+= -m$(BITS) -D__KERNEL__ -O2 \
 				   -fPIC -fno-strict-aliasing -mno-red-zone \
 				   -mno-mmx -mno-sse
 
-cflags-$(CONFIG_ARM64)		:= $(subst -pg,,$(KBUILD_CFLAGS))
+cflags-$(CONFIG_ARM64)		:= $(subst -pg,,$(KBUILD_CFLAGS)) -fpie
 cflags-$(CONFIG_ARM)		:= $(subst -pg,,$(KBUILD_CFLAGS)) \
 				   -fno-builtin -fpic -mno-single-pic-base