From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932780AbdKPLoI (ORCPT ); Thu, 16 Nov 2017 06:44:08 -0500 Received: from foss.arm.com ([217.140.101.70]:49844 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751152AbdKPLn6 (ORCPT ); Thu, 16 Nov 2017 06:43:58 -0500 Date: Thu, 16 Nov 2017 11:44:06 +0000 From: Will Deacon To: Ard Biesheuvel Cc: Sami Tolvanen , Mark Rutland , Andi Kleen , Kees Cook , linux-kbuild@vger.kernel.org, Nick Desaulniers , "linux-kernel@vger.kernel.org" , Greg Hackmann , Masahiro Yamada , Michal Marek , Yury Norov , Alex Matveev , Matthias Kaehlcke , "linux-arm-kernel@lists.infradead.org" , Maxim Kuvyrkov Subject: Re: [PATCH v2 08/18] arm64: don't disable ADR_PREL_PG_HI21* with ARM64_ERRATUM_843419 Message-ID: <20171116114406.GB9361@arm.com> References: <20171115213428.22559-1-samitolvanen@google.com> <20171115213428.22559-9-samitolvanen@google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Nov 15, 2017 at 10:29:12PM +0000, Ard Biesheuvel wrote: > On 15 November 2017 at 21:34, Sami Tolvanen wrote: > > CONFIG_LTO_CLANG depends on GNU gold, which can generate ADR_PREL_PG_HI21* > > relocations even with --fix-cortex-a53-843419. > > > > Signed-off-by: Sami Tolvanen > > --- > > arch/arm64/kernel/module.c | 2 -- > > 1 file changed, 2 deletions(-) > > > > diff --git a/arch/arm64/kernel/module.c b/arch/arm64/kernel/module.c > > index f469e0435903..fec9a578f122 100644 > > --- a/arch/arm64/kernel/module.c > > +++ b/arch/arm64/kernel/module.c > > @@ -336,14 +336,12 @@ 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.15.0.448.gf294e3d99a-goog > > > > I think this change is reasonable in itself, but i do wonder how we > can ensure that the adrp instructions that GNU gold does generate are > not affected by the erratum, given that modules are partially linked > object files, not shared libraries. Right, and this would also mean that we silently load vulnerable modules that are linked with either LD that doesn't support --fix-cortex-a53-843419 or simply wasn't passed. Will From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from foss.arm.com ([217.140.101.70]:49844 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751152AbdKPLn6 (ORCPT ); Thu, 16 Nov 2017 06:43:58 -0500 Date: Thu, 16 Nov 2017 11:44:06 +0000 From: Will Deacon Subject: Re: [PATCH v2 08/18] arm64: don't disable ADR_PREL_PG_HI21* with ARM64_ERRATUM_843419 Message-ID: <20171116114406.GB9361@arm.com> References: <20171115213428.22559-1-samitolvanen@google.com> <20171115213428.22559-9-samitolvanen@google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Sender: linux-kbuild-owner@vger.kernel.org List-ID: To: Ard Biesheuvel Cc: Sami Tolvanen , Mark Rutland , Andi Kleen , Kees Cook , linux-kbuild@vger.kernel.org, Nick Desaulniers , "linux-kernel@vger.kernel.org" , Greg Hackmann , Masahiro Yamada , Michal Marek , Yury Norov , Alex Matveev , Matthias Kaehlcke , "linux-arm-kernel@lists.infradead.org" , Maxim Kuvyrkov On Wed, Nov 15, 2017 at 10:29:12PM +0000, Ard Biesheuvel wrote: > On 15 November 2017 at 21:34, Sami Tolvanen wrote: > > CONFIG_LTO_CLANG depends on GNU gold, which can generate ADR_PREL_PG_HI21* > > relocations even with --fix-cortex-a53-843419. > > > > Signed-off-by: Sami Tolvanen > > --- > > arch/arm64/kernel/module.c | 2 -- > > 1 file changed, 2 deletions(-) > > > > diff --git a/arch/arm64/kernel/module.c b/arch/arm64/kernel/module.c > > index f469e0435903..fec9a578f122 100644 > > --- a/arch/arm64/kernel/module.c > > +++ b/arch/arm64/kernel/module.c > > @@ -336,14 +336,12 @@ 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.15.0.448.gf294e3d99a-goog > > > > I think this change is reasonable in itself, but i do wonder how we > can ensure that the adrp instructions that GNU gold does generate are > not affected by the erratum, given that modules are partially linked > object files, not shared libraries. Right, and this would also mean that we silently load vulnerable modules that are linked with either LD that doesn't support --fix-cortex-a53-843419 or simply wasn't passed. Will From mboxrd@z Thu Jan 1 00:00:00 1970 From: will.deacon@arm.com (Will Deacon) Date: Thu, 16 Nov 2017 11:44:06 +0000 Subject: [PATCH v2 08/18] arm64: don't disable ADR_PREL_PG_HI21* with ARM64_ERRATUM_843419 In-Reply-To: References: <20171115213428.22559-1-samitolvanen@google.com> <20171115213428.22559-9-samitolvanen@google.com> Message-ID: <20171116114406.GB9361@arm.com> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On Wed, Nov 15, 2017 at 10:29:12PM +0000, Ard Biesheuvel wrote: > On 15 November 2017 at 21:34, Sami Tolvanen wrote: > > CONFIG_LTO_CLANG depends on GNU gold, which can generate ADR_PREL_PG_HI21* > > relocations even with --fix-cortex-a53-843419. > > > > Signed-off-by: Sami Tolvanen > > --- > > arch/arm64/kernel/module.c | 2 -- > > 1 file changed, 2 deletions(-) > > > > diff --git a/arch/arm64/kernel/module.c b/arch/arm64/kernel/module.c > > index f469e0435903..fec9a578f122 100644 > > --- a/arch/arm64/kernel/module.c > > +++ b/arch/arm64/kernel/module.c > > @@ -336,14 +336,12 @@ 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.15.0.448.gf294e3d99a-goog > > > > I think this change is reasonable in itself, but i do wonder how we > can ensure that the adrp instructions that GNU gold does generate are > not affected by the erratum, given that modules are partially linked > object files, not shared libraries. Right, and this would also mean that we silently load vulnerable modules that are linked with either LD that doesn't support --fix-cortex-a53-843419 or simply wasn't passed. Will