Message ID | 20170518090953.32628-4-ard.biesheuvel@linaro.org |
---|---|
State | Accepted |
Commit | 91ee5b21ee026c49e4e7483de69b55b8b47042be |
Headers | show |
Series | efi: arm64: use -fpie for building the stub | expand |
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> -- To unsubscribe from this list: send the line "unsubscribe linux-efi" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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? -- To unsubscribe from this list: send the line "unsubscribe linux-efi" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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. -- To unsubscribe from this list: send the line "unsubscribe linux-efi" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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
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(-) -- 2.9.3 -- To unsubscribe from this list: send the line "unsubscribe linux-efi" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html