Received: by 2002:a05:6a10:f347:0:0:0:0 with SMTP id d7csp1350626pxu; Sat, 5 Dec 2020 12:42:51 -0800 (PST) X-Google-Smtp-Source: ABdhPJyFk6UK5/fiiiE4ovmwRiuoQnqVM1jonuyC3UtYjuls4+hN9F1lcsY5XasTb9qfnrYn7a6S X-Received: by 2002:a50:fb13:: with SMTP id d19mr13282279edq.133.1607200970799; Sat, 05 Dec 2020 12:42:50 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1607200970; cv=none; d=google.com; s=arc-20160816; b=UZ/bKVQrmxTewA/B9/m8SmpTijtfMYUliqu8HMRxOpPUpCwK1OqUUF1ZDPFnvfUb99 4b6EvbiGm1hM9ymdGgdOCPWvI/X8Sqp1D6JmaK+TeWFe6M7IhovK2z7HxzWAi3+petf5 M/ZQ13NZm2nVux6tcPeW/8ZWzp0zo9TnvwGn2KfYPfaJ5depxpMVp775ybN0f+sHoTzt aQMZ/HGD/rr+QmZoG9f6254NfE2nPvEJQUiEaJBbalKPiemkBGGjFHQCu4aXnAOHLWYY dAF0FHial33U4dUhhS4MH7+YF0KBcZ9LE7HyLN56OA8I3ttF8SETZRwGHnxeL7+ANDDd I63A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date; bh=xi9YvYLz9KzvhBwTvakjRUs8568h0QuWF+4Ntb4xX/M=; b=XCejPpTaBUl7WUKgDVyoU6gfNiqj7LZUDsJPaQIm7/JKmrgte7HUwViGu31DZF85cK +YELHLdST2MCxegIxZhCZiiNnVjNNF+CQFR4KMPX8lAAIdq9+oVaU8BqqtDpwvO3rj8i 59/sGJnnuANr4R858VGnp1w6b2t0BhtjPQMuEp65nPulMaMGhhoT5NHIfGj2ULq/OCv5 o4vIBOGTOt9LK1SxEbgG0kxiO8WJ7/q0cLs/AlCOJ7CeiFKkxC0i1ADQ6xwBNBaObYsj AJLdcqT4qsfO4T17GtxcicJ7FcA2kbWi8AV/HgzDS3t8jVElpNWefZ4xp1azj2oHWRXc N7lw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=canonical.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id x101si5382633ede.118.2020.12.05.12.42.27; Sat, 05 Dec 2020 12:42:50 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=canonical.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726024AbgLEUkR (ORCPT + 99 others); Sat, 5 Dec 2020 15:40:17 -0500 Received: from youngberry.canonical.com ([91.189.89.112]:46750 "EHLO youngberry.canonical.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725379AbgLEUkQ (ORCPT ); Sat, 5 Dec 2020 15:40:16 -0500 Received: from mail-io1-f70.google.com ([209.85.166.70]) by youngberry.canonical.com with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.86_2) (envelope-from ) id 1kleL7-0002sT-4f for linux-kernel@vger.kernel.org; Sat, 05 Dec 2020 20:39:33 +0000 Received: by mail-io1-f70.google.com with SMTP id j10so8155821iog.22 for ; Sat, 05 Dec 2020 12:39:33 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=xi9YvYLz9KzvhBwTvakjRUs8568h0QuWF+4Ntb4xX/M=; b=toXPTsANUHZDO4i0xRFolAx/6nilLkd9mCTsV7Ch5t0m7vOhucb/0OEHA8pkNCIwz8 DrVYMxhMNJzM9WO9giF5YZZOJW7d8SGmutuVdKFIPkaJcF1y1VLnw7CczVhmd3RN0uvJ 7tk1zKi4yokt8+PCEkSYJiZrZzro2e9i4Ibv2N2xomGqFJq+ZUa7f3oqyI2KYJmLYRQA Rs0T47QjvELqLDVXWVNvlHnoWM1TrU9mzpt24DT3gvzSciblfG9jK7ICYVnF3cgMFfpq b+zYmd2XQ5ifhelVadr/io0AyUvsKd9dJI5x8cgSSjQ2p1sCLizGeDdzeQkFzmy9+hol Nhag== X-Gm-Message-State: AOAM532WSt+ZIPkKaKsQsJfiLM29I5d/9i+RPnhZN3wNBB6NUt2KT7NR 7TLezCfAFnHkMusnU77N91yN9VahrdaW45i8CtxYLKBleEqQ9NlveMHy0CWuvkbmyV6QHQcd8zy 3PSSvKLu2cwDAIw3ejeIo3E1WYAcxl6nud8G9ua9a7A== X-Received: by 2002:a92:d283:: with SMTP id p3mr2418399ilp.265.1607200771896; Sat, 05 Dec 2020 12:39:31 -0800 (PST) X-Received: by 2002:a92:d283:: with SMTP id p3mr2418381ilp.265.1607200771604; Sat, 05 Dec 2020 12:39:31 -0800 (PST) Received: from xps13.dannf (c-71-56-235-36.hsd1.co.comcast.net. [71.56.235.36]) by smtp.gmail.com with ESMTPSA id p21sm1624193ilb.10.2020.12.05.12.39.29 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 05 Dec 2020 12:39:30 -0800 (PST) Date: Sat, 5 Dec 2020 13:39:28 -0700 From: dann frazier To: Greg Kroah-Hartman Cc: linux-kernel@vger.kernel.org, stable@vger.kernel.org, Ard Biesheuvel , Matthias Kaehlcke , Herbert Xu , Nathan Chancellor Subject: Re: [PATCH 4.4 17/70] crypto: arm64/sha - avoid non-standard inline asm tricks Message-ID: References: <20181126105046.722096341@linuxfoundation.org> <20181126105048.515352194@linuxfoundation.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Nov 23, 2020 at 01:49:07PM -0700, dann frazier wrote: > On Mon, Nov 26, 2018 at 11:50:32AM +0100, Greg Kroah-Hartman wrote: > > 4.4-stable review patch. If anyone has any objections, please let me know. > > fyi, I bisected a regression down to this commit. This apparently > causes an ADR_PREL_PG_HI21 relocation to be added to the sha{1,2}_ce > modules. Back in 4.4 ADR_PREL_PG_HI21 relocations were forbidden if > built with CONFIG_ARM64_ERRATUM_843419=y, so now the sha{1,2}_ce modules > fail to load: > > [ 37.866250] module sha1_ce: unsupported RELA relocation: 275 > > Looks like it should be an issue for 4.14.y as well, but I haven't yet > tested it. This regression appears to be limited to 4.4.y. I didn't find it when testing 4.9.y, and a 2nd bisection determined that it is because 4.9.y+ also contains a backport of commit 41c066f ("arm64: assembler: make adr_l work in modules under KASLR"). That was pulled from 4.4.y because it caused a build failure: https://www.spinics.net/lists/stable/msg179709.html Shall I submit a revert of this patch for 4.4.y, or is it worth trying to get a backport of 41c066f to work? -dann > > From: Ard Biesheuvel > > > > commit f4857f4c2ee9aa4e2aacac1a845352b00197fb57 upstream. > > > > Replace the inline asm which exports struct offsets as ELF symbols > > with proper const variables exposing the same values. This works > > around an issue with Clang which does not interpret the "i" (or "I") > > constraints in the same way as GCC. > > > > Signed-off-by: Ard Biesheuvel > > Tested-by: Matthias Kaehlcke > > Signed-off-by: Herbert Xu > > Signed-off-by: Nathan Chancellor > > Signed-off-by: Greg Kroah-Hartman > > --- > > arch/arm64/crypto/sha1-ce-core.S | 6 ++++-- > > arch/arm64/crypto/sha1-ce-glue.c | 11 +++-------- > > arch/arm64/crypto/sha2-ce-core.S | 6 ++++-- > > arch/arm64/crypto/sha2-ce-glue.c | 13 +++++-------- > > 4 files changed, 16 insertions(+), 20 deletions(-) > > > > --- a/arch/arm64/crypto/sha1-ce-core.S > > +++ b/arch/arm64/crypto/sha1-ce-core.S > > @@ -82,7 +82,8 @@ ENTRY(sha1_ce_transform) > > ldr dgb, [x0, #16] > > > > /* load sha1_ce_state::finalize */ > > - ldr w4, [x0, #:lo12:sha1_ce_offsetof_finalize] > > + ldr_l w4, sha1_ce_offsetof_finalize, x4 > > + ldr w4, [x0, x4] > > > > /* load input */ > > 0: ld1 {v8.4s-v11.4s}, [x1], #64 > > @@ -132,7 +133,8 @@ CPU_LE( rev32 v11.16b, v11.16b ) > > * the padding is handled by the C code in that case. > > */ > > cbz x4, 3f > > - ldr x4, [x0, #:lo12:sha1_ce_offsetof_count] > > + ldr_l w4, sha1_ce_offsetof_count, x4 > > + ldr x4, [x0, x4] > > movi v9.2d, #0 > > mov x8, #0x80000000 > > movi v10.2d, #0 > > --- a/arch/arm64/crypto/sha1-ce-glue.c > > +++ b/arch/arm64/crypto/sha1-ce-glue.c > > @@ -17,9 +17,6 @@ > > #include > > #include > > > > -#define ASM_EXPORT(sym, val) \ > > - asm(".globl " #sym "; .set " #sym ", %0" :: "I"(val)); > > - > > MODULE_DESCRIPTION("SHA1 secure hash using ARMv8 Crypto Extensions"); > > MODULE_AUTHOR("Ard Biesheuvel "); > > MODULE_LICENSE("GPL v2"); > > @@ -32,6 +29,9 @@ struct sha1_ce_state { > > asmlinkage void sha1_ce_transform(struct sha1_ce_state *sst, u8 const *src, > > int blocks); > > > > +const u32 sha1_ce_offsetof_count = offsetof(struct sha1_ce_state, sst.count); > > +const u32 sha1_ce_offsetof_finalize = offsetof(struct sha1_ce_state, finalize); > > + > > static int sha1_ce_update(struct shash_desc *desc, const u8 *data, > > unsigned int len) > > { > > @@ -52,11 +52,6 @@ static int sha1_ce_finup(struct shash_de > > struct sha1_ce_state *sctx = shash_desc_ctx(desc); > > bool finalize = !sctx->sst.count && !(len % SHA1_BLOCK_SIZE); > > > > - ASM_EXPORT(sha1_ce_offsetof_count, > > - offsetof(struct sha1_ce_state, sst.count)); > > - ASM_EXPORT(sha1_ce_offsetof_finalize, > > - offsetof(struct sha1_ce_state, finalize)); > > - > > /* > > * Allow the asm code to perform the finalization if there is no > > * partial data and the input is a round multiple of the block size. > > --- a/arch/arm64/crypto/sha2-ce-core.S > > +++ b/arch/arm64/crypto/sha2-ce-core.S > > @@ -88,7 +88,8 @@ ENTRY(sha2_ce_transform) > > ld1 {dgav.4s, dgbv.4s}, [x0] > > > > /* load sha256_ce_state::finalize */ > > - ldr w4, [x0, #:lo12:sha256_ce_offsetof_finalize] > > + ldr_l w4, sha256_ce_offsetof_finalize, x4 > > + ldr w4, [x0, x4] > > > > /* load input */ > > 0: ld1 {v16.4s-v19.4s}, [x1], #64 > > @@ -136,7 +137,8 @@ CPU_LE( rev32 v19.16b, v19.16b ) > > * the padding is handled by the C code in that case. > > */ > > cbz x4, 3f > > - ldr x4, [x0, #:lo12:sha256_ce_offsetof_count] > > + ldr_l w4, sha256_ce_offsetof_count, x4 > > + ldr x4, [x0, x4] > > movi v17.2d, #0 > > mov x8, #0x80000000 > > movi v18.2d, #0 > > --- a/arch/arm64/crypto/sha2-ce-glue.c > > +++ b/arch/arm64/crypto/sha2-ce-glue.c > > @@ -17,9 +17,6 @@ > > #include > > #include > > > > -#define ASM_EXPORT(sym, val) \ > > - asm(".globl " #sym "; .set " #sym ", %0" :: "I"(val)); > > - > > MODULE_DESCRIPTION("SHA-224/SHA-256 secure hash using ARMv8 Crypto Extensions"); > > MODULE_AUTHOR("Ard Biesheuvel "); > > MODULE_LICENSE("GPL v2"); > > @@ -32,6 +29,11 @@ struct sha256_ce_state { > > asmlinkage void sha2_ce_transform(struct sha256_ce_state *sst, u8 const *src, > > int blocks); > > > > +const u32 sha256_ce_offsetof_count = offsetof(struct sha256_ce_state, > > + sst.count); > > +const u32 sha256_ce_offsetof_finalize = offsetof(struct sha256_ce_state, > > + finalize); > > + > > static int sha256_ce_update(struct shash_desc *desc, const u8 *data, > > unsigned int len) > > { > > @@ -52,11 +54,6 @@ static int sha256_ce_finup(struct shash_ > > struct sha256_ce_state *sctx = shash_desc_ctx(desc); > > bool finalize = !sctx->sst.count && !(len % SHA256_BLOCK_SIZE); > > > > - ASM_EXPORT(sha256_ce_offsetof_count, > > - offsetof(struct sha256_ce_state, sst.count)); > > - ASM_EXPORT(sha256_ce_offsetof_finalize, > > - offsetof(struct sha256_ce_state, finalize)); > > - > > /* > > * Allow the asm code to perform the finalization if there is no > > * partial data and the input is a round multiple of the block size. > > > >