arm64: errata: add module build workaround for erratum #843419
PATCH 1/1 arm64: errata: add module build workaround for erratum #843419
Cortex-A53 processors <= r0p4 are affected by erratum #843419 which can lead to a memory access using an incorrect address in certain sequences headed by an ADRP instruction.
There is a linker fix to generate veneers for ADRP instructions, but this doesn't work for kernel modules which are built as unlinked ELF objects.
This patch adds a new config option for the erratum which, when enabled, builds kernel modules with the mcmodel=large flag. This uses absolute addressing for all kernel symbols, thereby removing the use of ADRP as a PC-relative form of addressing. The ADRP relocs are removed from the module loader so that we fail to load any potentially affected modules.
--- arch/arm64/Kconfig | 16 ++++++++++++++++ arch/arm64/Makefile | 4 ++++ arch/arm64/kernel/module.c | 2 ++ 3 files changed, 22 insertions(+)
arch/arm64/Kconfig +16 -0
@@ -331,6 +331,22 @@ config ARM64_ERRATUM_845719 If unsure, say Y. +config ARM64_ERRATUM_843419 + bool "Cortex-A53: 843419: A load or store might access an incorrect address" + depends on MODULES + default y + help + This option builds kernel modules using the large memory model in + order to avoid the use of the ADRP instruction, which can cause + a subsequent memory access to use an incorrect address on Cortex-A53 + parts up to r0p4. + + Note that the kernel itself must be linked with a version of ld + which fixes potentially affected ADRP instructions through the + use of veneers. + + If unsure, say Y. + endmenu
arch/arm64/Makefile +4 -0
@@ -41,6 +41,10 @@ endif CHECKFLAGS += -D__aarch64__ +ifeq ($(CONFIG_ARM64_ERRATUM_843419), y) +CFLAGS_MODULE += -mcmodel=large +endif + # Default value head-y := arch/arm64/kernel/head.o
arch/arm64/kernel/module.c +2 -0
@@ -332,12 +332,14 @@ int apply_relocate_add(Elf64_Shdr *sechdrs, ovf =reloc_insn_imm (RELOC_OP_PREL , loc, val,0 ,21 ,AARCH64_INSN_IMM_ADR );break ; +#ifndef CONFIG_ARM64_ERRATUM_843419 case R_AARCH64_ADR_PREL_PG_HI21_NC : overflow_check = false;case R_AARCH64_ADR_PREL_PG_HI21 : ovf =reloc_insn_imm (RELOC_OP_PAGE , loc, val,12 ,21 ,AARCH64_INSN_IMM_ADR );break ; +#endif case R_AARCH64_ADD_ABS_LO12_NC :case R_AARCH64_LDST8_ABS_LO12_NC : overflow_check = false;
Signature · 1 line
2.1.4
Catalin Marinas
maintainerPATCH 1/1 arm64: errata: add module build workaround for erratum #843419
Quoted 8 lines · Will Deacon
Cortex-A53 processors <= r0p4 are affected by erratum #843419 which can lead to a memory access using an incorrect address in certain sequences headed by an ADRP instruction.
There is a linker fix to generate veneers for ADRP instructions, but this doesn't work for kernel modules which are built as unlinked ELF objects.
Quoted 7 lines
This patch adds a new config option for the erratum which, when enabled, builds kernel modules with the mcmodel=large flag. This uses absolute addressing for all kernel symbols, thereby removing the use of ADRP as a PC-relative form of addressing. The ADRP relocs are removed from the module loader so that we fail to load any potentially affected modules.
Signed-off-by Will Deacon <[email protected]>
I don't particularly like but, well...
PATCH 1/1 arm64: errata: add module build workaround for erratum #843419
In reply to Will DeaconHi Will,
Quoted 8 lines · Will Deacon
Cortex-A53 processors <= r0p4 are affected by erratum #843419 which can lead to a memory access using an incorrect address in certain sequences headed by an ADRP instruction.
There is a linker fix to generate veneers for ADRP instructions, but this doesn't work for kernel modules which are built as unlinked ELF objects.
Considering that the kernel is built without -fpic but still appears at a different offset when the MMU is off, those veneers had better be position independent.
Quoted 45 lines
This patch adds a new config option for the erratum which, when enabled, builds kernel modules with the mcmodel=large flag. This uses absolute addressing for all kernel symbols, thereby removing the use of ADRP as a PC-relative form of addressing. The ADRP relocs are removed from the module loader so that we fail to load any potentially affected modules.
Signed-off-by Will Deacon <[email protected]>--- arch/arm64/Kconfig | 16 ++++++++++++++++ arch/arm64/Makefile | 4 ++++ arch/arm64/kernel/module.c | 2 ++ 3 files changed, 22 insertions(+)arch/arm64/Kconfig +16
-0@@ -331,6 +331,22 @@ config ARM64_ERRATUM_845719 If unsure, say Y. +config ARM64_ERRATUM_843419 + bool "Cortex-A53: 843419: A load or store might access an incorrect address" + depends on MODULES + default y + help + This option builds kernel modules using the large memory model in + order to avoid the use of the ADRP instruction, which can cause + a subsequent memory access to use an incorrect address on Cortex-A53 + parts up to r0p4. + + Note that the kernel itself must be linked with a version of ld + which fixes potentially affected ADRP instructions through the + use of veneers. + + If unsure, say Y. + endmenuarch/arm64/Makefile +0
-0
arch/arm64/Makefile endif · line 47
Quoted 7 lines
arch/arm64/Makefile +4
-0@@ -41,6 +41,10 @@ endif CHECKFLAGS += -D__aarch64__ +ifeq ($(CONFIG_ARM64_ERRATUM_843419), y) +CFLAGS_MODULE += -mcmodel=large +endif +
Ouch.
Couldn't we handle this at runtime? According to the erratum, the problem only occurs when the adrp is in either of the last two instruction slots of a 4 KB page, and we could easily turn adrp instructions into adr if the symbol is within 1 MB of the place (which would typically cover all internal references in the module), and emit a veneer otherwise?
I'm happy to hack something up
Quoted 30 lines
arch/arm64/Makefile +0
-0# Default value head-y := arch/arm64/kernel/head.oarch/arm64/kernel/module.c +2
-1@@ -332,12 +332,14 @@ int apply_relocate_add(Elf64_Shdr *sechdrs, ovf =reloc_insn_imm (RELOC_OP_PREL , loc, val,0 ,21 ,AARCH64_INSN_IMM_ADR );break ; +#ifndef CONFIG_ARM64_ERRATUM_843419 case R_AARCH64_ADR_PREL_PG_HI21_NC : overflow_check = false;case R_AARCH64_ADR_PREL_PG_HI21 : ovf =reloc_insn_imm (RELOC_OP_PAGE , loc, val,12 ,21 ,AARCH64_INSN_IMM_ADR );break ; +#endif case R_AARCH64_ADD_ABS_LO12_NC :case R_AARCH64_LDST8_ABS_LO12_NC : overflow_check = false; --2.1.4
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel at lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
PATCH 1/1 arm64: errata: add module build workaround for erratum #843419
Quoted 1 line · Ard Biesheuvel
Hi Will,
Hi Ard,
Quoted 5 lines · Will Deacon
Quoted 4 lines
Cortex-A53 processors <= r0p4 are affected by erratum #843419 which can lead to a memory access using an incorrect address in certain sequences headed by an ADRP instruction.
Quoted 8 lines
Quoted 4 lines
There is a linker fix to generate veneers for ADRP instructions, but this doesn't work for kernel modules which are built as unlinked ELF objects.
Considering that the kernel is built without -fpic but still appears at a different offset when the MMU is off, those veneers had better be position independent.
They seem to be ok, from what I've tested. You should also be able to take a recent ld and see for yourself what it gets up to.
Quoted 55 lines
Quoted 45 lines
This patch adds a new config option for the erratum which, when enabled, builds kernel modules with the mcmodel=large flag. This uses absolute addressing for all kernel symbols, thereby removing the use of ADRP as a PC-relative form of addressing. The ADRP relocs are removed from the module loader so that we fail to load any potentially affected modules.
Signed-off-by Will Deacon <[email protected]>--- arch/arm64/Kconfig | 16 ++++++++++++++++ arch/arm64/Makefile | 4 ++++ arch/arm64/kernel/module.c | 2 ++ 3 files changed, 22 insertions(+)arch/arm64/Kconfig +16
-0@@ -331,6 +331,22 @@ config ARM64_ERRATUM_845719 If unsure, say Y. +config ARM64_ERRATUM_843419 + bool "Cortex-A53: 843419: A load or store might access an incorrect address" + depends on MODULES + default y + help + This option builds kernel modules using the large memory model in + order to avoid the use of the ADRP instruction, which can cause + a subsequent memory access to use an incorrect address on Cortex-A53 + parts up to r0p4. + + Note that the kernel itself must be linked with a version of ld + which fixes potentially affected ADRP instructions through the + use of veneers. + + If unsure, say Y. + endmenuarch/arm64/Makefile +0
-0arch/arm64/Makefile endif · line 47
Quoted 7 lines
arch/arm64/Makefile +4
-0@@ -41,6 +41,10 @@ endif CHECKFLAGS += -D__aarch64__ +ifeq ($(CONFIG_ARM64_ERRATUM_843419), y) +CFLAGS_MODULE += -mcmodel=large +endif +Ouch.
Quoted 6 lines
Couldn't we handle this at runtime? According to the erratum, the problem only occurs when the adrp is in either of the last two instruction slots of a 4 KB page, and we could easily turn adrp instructions into adr if the symbol is within 1 MB of the place (which would typically cover all internal references in the module), and emit a veneer otherwise?
I'd have thought the internal references would already be using smaller relocs if they could get away with it, but it's worth looking at.
Quoted 1 line
I'm happy to hack something up
Sure, fill your boots! I just wanted something simple for stable and I have limited patience in working around these kind of things. I think there are some testcases in the binutils tree if you want to adapt them for the module loader [1].
Will
[1]
https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=blob;f=ld/testsuite/ld-aarch64/erratum843419.s;h=35c21ae95a65913050dafc857abe35d8ee6fe9ed;hb=HEAD
https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=blob;f=ld/testsuite/ld-aarch64/erratum843419.d;h=4be8f9e585095898dae9a8677d565edb4089e97a;hb=HEAD
PATCH 1/1 arm64: errata: add module build workaround for erratum #843419
In reply to Will DeaconQuoted 3 lines · Will Deacon
Cortex-A53 processors <= r0p4 are affected by erratum #843419 which can lead to a memory access using an incorrect address in certain sequences headed by an ADRP instruction.
Just a heads up that we're seeing a regression in the Ubuntu 4.2 kernel on X-Gene after this patch is applied and the CONFIG enabled.
Modules loads fail with messages like:
[ 2.192721] module gpio_xgene_sb: unsupported RELA relocation: 275 [ 2.193609] module xgene_enet: unsupported RELA relocation: 275 [ 2.249402] module libahci: unsupported RELA relocation: 275 [ 2.249628] module xgene_enet: unsupported RELA relocation: 275 [ 2.359451] module xgene_enet: unsupported RELA relocation: 275 [ 2.389444] module xgene_enet: unsupported RELA relocation: 275 [ 3.473766] module linear: unsupported RELA relocation: 275 [ 3.543252] module multipath: unsupported RELA relocation: 275 [ 3.593268] module raid0: unsupported RELA relocation: 275 [ 3.663695] module raid1: unsupported RELA relocation: 275 [ 3.713964] module raid6_pq: unsupported RELA relocation: 275 [ 3.763983] module raid6_pq: unsupported RELA relocation: 275 [ 3.803975] module raid6_pq: unsupported RELA relocation: 275 [ 3.853881] module raid10: unsupported RELA relocation: 275 [ 3.924962] module raid6_pq: unsupported RELA relocation: 275
I haven't attempted to reproduce with a pure upstream kernel yet.
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1502946
-dann
Quoted 86 lines
There is a linker fix to generate veneers for ADRP instructions, but this doesn't work for kernel modules which are built as unlinked ELF objects.
This patch adds a new config option for the erratum which, when enabled, builds kernel modules with the mcmodel=large flag. This uses absolute addressing for all kernel symbols, thereby removing the use of ADRP as a PC-relative form of addressing. The ADRP relocs are removed from the module loader so that we fail to load any potentially affected modules.
Signed-off-by Will Deacon <[email protected]>--- arch/arm64/Kconfig | 16 ++++++++++++++++ arch/arm64/Makefile | 4 ++++ arch/arm64/kernel/module.c | 2 ++ 3 files changed, 22 insertions(+)arch/arm64/Kconfig +16
-0@@ -331,6 +331,22 @@ config ARM64_ERRATUM_845719 If unsure, say Y. +config ARM64_ERRATUM_843419 + bool "Cortex-A53: 843419: A load or store might access an incorrect address" + depends on MODULES + default y + help + This option builds kernel modules using the large memory model in + order to avoid the use of the ADRP instruction, which can cause + a subsequent memory access to use an incorrect address on Cortex-A53 + parts up to r0p4. + + Note that the kernel itself must be linked with a version of ld + which fixes potentially affected ADRP instructions through the + use of veneers. + + If unsure, say Y. + endmenuarch/arm64/Makefile +4
-0@@ -41,6 +41,10 @@ endif CHECKFLAGS += -D__aarch64__ +ifeq ($(CONFIG_ARM64_ERRATUM_843419), y) +CFLAGS_MODULE += -mcmodel=large +endif + # Default value head-y := arch/arm64/kernel/head.oarch/arm64/kernel/module.c +2
-1@@ -332,12 +332,14 @@ int apply_relocate_add(Elf64_Shdr *sechdrs, ovf =reloc_insn_imm (RELOC_OP_PREL , loc, val,0 ,21 ,AARCH64_INSN_IMM_ADR );break ; +#ifndef CONFIG_ARM64_ERRATUM_843419 case R_AARCH64_ADR_PREL_PG_HI21_NC : overflow_check = false;case R_AARCH64_ADR_PREL_PG_HI21 : ovf =reloc_insn_imm (RELOC_OP_PAGE , loc, val,12 ,21 ,AARCH64_INSN_IMM_ADR );break ; +#endif case R_AARCH64_ADD_ABS_LO12_NC :case R_AARCH64_LDST8_ABS_LO12_NC : overflow_check = false; --2.1.4
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel at lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
PATCH 1/1 arm64: errata: add module build workaround for erratum #843419
Quoted 10 lines · Dann Frazier
Quoted 3 lines · Will Deacon
Cortex-A53 processors <= r0p4 are affected by erratum #843419 which can lead to a memory access using an incorrect address in certain sequences headed by an ADRP instruction.
Just a heads up that we're seeing a regression in the Ubuntu 4.2 kernel on X-Gene after this patch is applied and the CONFIG enabled.
Modules loads fail with messages like:
Quoted 16 lines
[ 2.192721] module gpio_xgene_sb: unsupported RELA relocation: 275 [ 2.193609] module xgene_enet: unsupported RELA relocation: 275 [ 2.249402] module libahci: unsupported RELA relocation: 275 [ 2.249628] module xgene_enet: unsupported RELA relocation: 275 [ 2.359451] module xgene_enet: unsupported RELA relocation: 275 [ 2.389444] module xgene_enet: unsupported RELA relocation: 275 [ 3.473766] module linear: unsupported RELA relocation: 275 [ 3.543252] module multipath: unsupported RELA relocation: 275 [ 3.593268] module raid0: unsupported RELA relocation: 275 [ 3.663695] module raid1: unsupported RELA relocation: 275 [ 3.713964] module raid6_pq: unsupported RELA relocation: 275 [ 3.763983] module raid6_pq: unsupported RELA relocation: 275 [ 3.803975] module raid6_pq: unsupported RELA relocation: 275 [ 3.853881] module raid10: unsupported RELA relocation: 275 [ 3.924962] module raid6_pq: unsupported RELA relocation: 275
RELA #275 is the relocation against ADRP instructions, which GCC should not emit anymore when -mcmodel=large is in effect.
Can you confirm that the modules have been rebuilt with this config as well? Can you double check the GCC command line (with V=1) when doing 'make modules' to ensure that '-mcmodel=large' is being passed? Can you check with 'readelf -r' which objects still contain R_AARCH64_ADR_PREL_PG_HI21 relocations?
Quoted 97 lines
I haven't attempted to reproduce with a pure upstream kernel yet.
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1502946
-dann
Quoted 82 lines
There is a linker fix to generate veneers for ADRP instructions, but this doesn't work for kernel modules which are built as unlinked ELF objects.
This patch adds a new config option for the erratum which, when enabled, builds kernel modules with the mcmodel=large flag. This uses absolute addressing for all kernel symbols, thereby removing the use of ADRP as a PC-relative form of addressing. The ADRP relocs are removed from the module loader so that we fail to load any potentially affected modules.
Signed-off-by Will Deacon <[email protected]>--- arch/arm64/Kconfig | 16 ++++++++++++++++ arch/arm64/Makefile | 4 ++++ arch/arm64/kernel/module.c | 2 ++ 3 files changed, 22 insertions(+)arch/arm64/Kconfig +16
-0@@ -331,6 +331,22 @@ config ARM64_ERRATUM_845719 If unsure, say Y. +config ARM64_ERRATUM_843419 + bool "Cortex-A53: 843419: A load or store might access an incorrect address" + depends on MODULES + default y + help + This option builds kernel modules using the large memory model in + order to avoid the use of the ADRP instruction, which can cause + a subsequent memory access to use an incorrect address on Cortex-A53 + parts up to r0p4. + + Note that the kernel itself must be linked with a version of ld + which fixes potentially affected ADRP instructions through the + use of veneers. + + If unsure, say Y. + endmenuarch/arm64/Makefile +4
-0@@ -41,6 +41,10 @@ endif CHECKFLAGS += -D__aarch64__ +ifeq ($(CONFIG_ARM64_ERRATUM_843419), y) +CFLAGS_MODULE += -mcmodel=large +endif + # Default value head-y := arch/arm64/kernel/head.oarch/arm64/kernel/module.c +2
-1@@ -332,12 +332,14 @@ int apply_relocate_add(Elf64_Shdr *sechdrs, ovf =reloc_insn_imm (RELOC_OP_PREL , loc, val,0 ,21 ,AARCH64_INSN_IMM_ADR );break ; +#ifndef CONFIG_ARM64_ERRATUM_843419 case R_AARCH64_ADR_PREL_PG_HI21_NC : overflow_check = false;case R_AARCH64_ADR_PREL_PG_HI21 : ovf =reloc_insn_imm (RELOC_OP_PAGE , loc, val,12 ,21 ,AARCH64_INSN_IMM_ADR );break ; +#endif case R_AARCH64_ADD_ABS_LO12_NC :case R_AARCH64_LDST8_ABS_LO12_NC : overflow_check = false; --2.1.4
Quoted 4 lines
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel at lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel at lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
PATCH 1/1 arm64: errata: add module build workaround for erratum #843419
Quoted 28 lines · Ard Biesheuvel
Quoted 10 lines · Dann Frazier
Quoted 3 lines · Will Deacon
Cortex-A53 processors <= r0p4 are affected by erratum #843419 which can lead to a memory access using an incorrect address in certain sequences headed by an ADRP instruction.
Just a heads up that we're seeing a regression in the Ubuntu 4.2 kernel on X-Gene after this patch is applied and the CONFIG enabled.
Modules loads fail with messages like:
Quoted 16 lines
[ 2.192721] module gpio_xgene_sb: unsupported RELA relocation: 275 [ 2.193609] module xgene_enet: unsupported RELA relocation: 275 [ 2.249402] module libahci: unsupported RELA relocation: 275 [ 2.249628] module xgene_enet: unsupported RELA relocation: 275 [ 2.359451] module xgene_enet: unsupported RELA relocation: 275 [ 2.389444] module xgene_enet: unsupported RELA relocation: 275 [ 3.473766] module linear: unsupported RELA relocation: 275 [ 3.543252] module multipath: unsupported RELA relocation: 275 [ 3.593268] module raid0: unsupported RELA relocation: 275 [ 3.663695] module raid1: unsupported RELA relocation: 275 [ 3.713964] module raid6_pq: unsupported RELA relocation: 275 [ 3.763983] module raid6_pq: unsupported RELA relocation: 275 [ 3.803975] module raid6_pq: unsupported RELA relocation: 275 [ 3.853881] module raid10: unsupported RELA relocation: 275 [ 3.924962] module raid6_pq: unsupported RELA relocation: 275
Quoted 5 lines
RELA #275 is the relocation against ADRP instructions, which GCC should not emit anymore when -mcmodel=large is in effect.
Can you confirm that the modules have been rebuilt with this config as well?
Yeah, it was.
Quoted 2 lines
Can you double check the GCC command line (with V=1) when doing 'make modules' to ensure that '-mcmodel=large' is being passed?
I did, and I don't see -mcmodel at all. On a whim I changed CFLAGS_MODULE in the patch to KBUILD_CFLAGS_MODULE, and V=1 now shows -mcmodel=large. I haven't had time yet to figure out why the KBUILD variant is important, nor time to boot test such a build (travel day).
Quoted 3 lines
Can
you check with 'readelf -r' which objects still containR_AARCH64_ADR_PREL_PG_HI21relocations?
My readelf seems to truncate the type field (even w/ -W). Let me know if you still need the list of objects after the above and I can try fixing it.
-dann
Quoted 99 lines
Quoted 99 lines
I haven't attempted to reproduce with a pure upstream kernel yet.
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1502946
-dann
Quoted 82 lines
There is a linker fix to generate veneers for ADRP instructions, but this doesn't work for kernel modules which are built as unlinked ELF objects.
This patch adds a new config option for the erratum which, when enabled, builds kernel modules with the mcmodel=large flag. This uses absolute addressing for all kernel symbols, thereby removing the use of ADRP as a PC-relative form of addressing. The ADRP relocs are removed from the module loader so that we fail to load any potentially affected modules.
Signed-off-by Will Deacon <[email protected]>--- arch/arm64/Kconfig | 16 ++++++++++++++++ arch/arm64/Makefile | 4 ++++ arch/arm64/kernel/module.c | 2 ++ 3 files changed, 22 insertions(+)arch/arm64/Kconfig +16
-0@@ -331,6 +331,22 @@ config ARM64_ERRATUM_845719 If unsure, say Y. +config ARM64_ERRATUM_843419 + bool "Cortex-A53: 843419: A load or store might access an incorrect address" + depends on MODULES + default y + help + This option builds kernel modules using the large memory model in + order to avoid the use of the ADRP instruction, which can cause + a subsequent memory access to use an incorrect address on Cortex-A53 + parts up to r0p4. + + Note that the kernel itself must be linked with a version of ld + which fixes potentially affected ADRP instructions through the + use of veneers. + + If unsure, say Y. + endmenuarch/arm64/Makefile +4
-0@@ -41,6 +41,10 @@ endif CHECKFLAGS += -D__aarch64__ +ifeq ($(CONFIG_ARM64_ERRATUM_843419), y) +CFLAGS_MODULE += -mcmodel=large +endif + # Default value head-y := arch/arm64/kernel/head.oarch/arm64/kernel/module.c +2
-1@@ -332,12 +332,14 @@ int apply_relocate_add(Elf64_Shdr *sechdrs, ovf =reloc_insn_imm (RELOC_OP_PREL , loc, val,0 ,21 ,AARCH64_INSN_IMM_ADR );break ; +#ifndef CONFIG_ARM64_ERRATUM_843419 case R_AARCH64_ADR_PREL_PG_HI21_NC : overflow_check = false;case R_AARCH64_ADR_PREL_PG_HI21 : ovf =reloc_insn_imm (RELOC_OP_PAGE , loc, val,12 ,21 ,AARCH64_INSN_IMM_ADR );break ; +#endif case R_AARCH64_ADD_ABS_LO12_NC :case R_AARCH64_LDST8_ABS_LO12_NC : overflow_check = false; --2.1.4
Quoted 4 lines
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel at lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel at lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
PATCH 1/1 arm64: errata: add module build workaround for erratum #843419
Quoted 38 lines · Dann Frazier
Quoted 28 lines · Ard Biesheuvel
Quoted 10 lines · Dann Frazier
Quoted 3 lines · Will Deacon
Cortex-A53 processors <= r0p4 are affected by erratum #843419 which can lead to a memory access using an incorrect address in certain sequences headed by an ADRP instruction.
Just a heads up that we're seeing a regression in the Ubuntu 4.2 kernel on X-Gene after this patch is applied and the CONFIG enabled.
Modules loads fail with messages like:
Quoted 16 lines
[ 2.192721] module gpio_xgene_sb: unsupported RELA relocation: 275 [ 2.193609] module xgene_enet: unsupported RELA relocation: 275 [ 2.249402] module libahci: unsupported RELA relocation: 275 [ 2.249628] module xgene_enet: unsupported RELA relocation: 275 [ 2.359451] module xgene_enet: unsupported RELA relocation: 275 [ 2.389444] module xgene_enet: unsupported RELA relocation: 275 [ 3.473766] module linear: unsupported RELA relocation: 275 [ 3.543252] module multipath: unsupported RELA relocation: 275 [ 3.593268] module raid0: unsupported RELA relocation: 275 [ 3.663695] module raid1: unsupported RELA relocation: 275 [ 3.713964] module raid6_pq: unsupported RELA relocation: 275 [ 3.763983] module raid6_pq: unsupported RELA relocation: 275 [ 3.803975] module raid6_pq: unsupported RELA relocation: 275 [ 3.853881] module raid10: unsupported RELA relocation: 275 [ 3.924962] module raid6_pq: unsupported RELA relocation: 275Quoted 5 lines
RELA #275 is the relocation against ADRP instructions, which GCC should not emit anymore when -mcmodel=large is in effect.
Can you confirm that the modules have been rebuilt with this config as well?
Yeah, it was.
Quoted 7 lines
Quoted 2 lines
Can you double check the GCC command line (with V=1) when doing 'make modules' to ensure that '-mcmodel=large' is being passed?
I did, and I don't see -mcmodel at all. On a whim I changed
CFLAGS_MODULEin the patch toKBUILD_CFLAGS_MODULE, and V=1 now shows -mcmodel=large. I haven't had time yet to figure out why the KBUILD variant is important, nor time to boot test such a build (travel day).
CFLAGS_MODULE is the environment variable (i.e. you can set it on the cmdline), so we probably *should* be using KBUILD_CFLAGS_MODULE here instead (and the thumb2 gas issue on arch/arm/ should be updated as well).
However, I'd still like to understand how it's getting clobbered for you. Are you overriding CFLAGS_MODULE someplace?
Will
PATCH 1/1 arm64: errata: add module build workaround for erratum #843419
Quoted 47 lines · Will Deacon
Quoted 38 lines · Dann Frazier
Quoted 28 lines · Ard Biesheuvel
Quoted 10 lines · Dann Frazier
Quoted 3 lines · Will Deacon
Cortex-A53 processors <= r0p4 are affected by erratum #843419 which can lead to a memory access using an incorrect address in certain sequences headed by an ADRP instruction.
Just a heads up that we're seeing a regression in the Ubuntu 4.2 kernel on X-Gene after this patch is applied and the CONFIG enabled.
Modules loads fail with messages like:
Quoted 16 lines
[ 2.192721] module gpio_xgene_sb: unsupported RELA relocation: 275 [ 2.193609] module xgene_enet: unsupported RELA relocation: 275 [ 2.249402] module libahci: unsupported RELA relocation: 275 [ 2.249628] module xgene_enet: unsupported RELA relocation: 275 [ 2.359451] module xgene_enet: unsupported RELA relocation: 275 [ 2.389444] module xgene_enet: unsupported RELA relocation: 275 [ 3.473766] module linear: unsupported RELA relocation: 275 [ 3.543252] module multipath: unsupported RELA relocation: 275 [ 3.593268] module raid0: unsupported RELA relocation: 275 [ 3.663695] module raid1: unsupported RELA relocation: 275 [ 3.713964] module raid6_pq: unsupported RELA relocation: 275 [ 3.763983] module raid6_pq: unsupported RELA relocation: 275 [ 3.803975] module raid6_pq: unsupported RELA relocation: 275 [ 3.853881] module raid10: unsupported RELA relocation: 275 [ 3.924962] module raid6_pq: unsupported RELA relocation: 275Quoted 5 lines
RELA #275 is the relocation against ADRP instructions, which GCC should not emit anymore when -mcmodel=large is in effect.
Can you confirm that the modules have been rebuilt with this config as well?
Yeah, it was.
Quoted 7 lines
Quoted 2 lines
Can you double check the GCC command line (with V=1) when doing 'make modules' to ensure that '-mcmodel=large' is being passed?
I did, and I don't see -mcmodel at all. On a whim I changed
CFLAGS_MODULEin the patch toKBUILD_CFLAGS_MODULE, and V=1 now shows -mcmodel=large. I haven't had time yet to figure out why the KBUILD variant is important, nor time to boot test such a build (travel day).
Quoted 7 lines
CFLAGS_MODULEis the environment variable (i.e. you can set it on the cmdline), so we probably *should* be usingKBUILD_CFLAGS_MODULEhere instead (and the thumb2 gas issue onarch/arm/should be updated as well).However, I'd still like to understand how it's getting clobbered for you. Are you overriding
CFLAGS_MODULEsomeplace?
Yep - apparently the Ubuntu kernel packaging uses it to pass the ABI number:
kmake = make ARCH=$(build_arch) \
CROSS_COMPILE=$(CROSS_COMPILE) \
KERNELVERSION=$(abi_release)-$(target_flavour) \
CONFIG_DEBUG_SECTION_MISMATCH=y \
KBUILD_BUILD_VERSION="$(uploadnum)" \
LOCALVERSION= localver-extra= \
CFLAGS_MODULE="-DPKG_ABI=$(abinum)"PATCH 1/1 arm64: errata: Use KCONFIG variant of CFLAGS_MODULE to avoid user override
Upstream commit df057cc7b4fa59e9b55f07ffdb6c62bf02e99a00 broke module loading in Ubuntu kernel builds:
[ 2.192721] module gpio_xgene_sb: unsupported RELA relocation: 275 [ 2.193609] module xgene_enet: unsupported RELA relocation: 275 [ 2.249402] module libahci: unsupported RELA relocation: 275
That commit added a flag to CFLAGS_MODULE, which is vulnerable to environment override. Ubuntu builds use this to pass in the ABI number, so it was getting clobbered.
To avoid overriding, use KCONFIG_CFLAGS_MODULE instead.
--- arch/arm64/Makefile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
arch/arm64/Makefile +1 -1
@@ -42,7 +42,7 @@ endif CHECKFLAGS += -D__aarch64__ ifeq ($(CONFIG_ARM64_ERRATUM_843419), y) -CFLAGS_MODULE += -mcmodel=large +KBUILD_CFLAGS_MODULE += -mcmodel=large endif # Default value
Signature · 1 line
2.6.1