Received: by 2002:a05:6358:1087:b0:cb:c9d3:cd90 with SMTP id j7csp5173707rwi; Mon, 17 Oct 2022 16:57:06 -0700 (PDT) X-Google-Smtp-Source: AMsMyM4/IhG7b9uP4KWWCHlOo/NjDM3oBhZLjcVGM+hbh+izzKFLkBVrRq3YsmGIW0i8tx1SP4fr X-Received: by 2002:aa7:cd92:0:b0:456:cbb5:2027 with SMTP id x18-20020aa7cd92000000b00456cbb52027mr176738edv.384.1666051026043; Mon, 17 Oct 2022 16:57:06 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1666051026; cv=none; d=google.com; s=arc-20160816; b=S9sDvbsgUtZbqNx1Fd1s3DMGOq7mkkfviKjLTUfqunaExG0f19fJ0gVptUMVJjAQnp xsg2eSluobNVGn6O1oXn6J/jMaRBFkUQoYP70iJ2H7NFmqSSIKqG80+5jacg+DkfHjYy Al98XidziV3FjXk+zZR155k7t/1Y29n4gB3Vmx60ZwMD/p0Wl7DY57E7LhhePnUByCFs HztZFs92fMeeMlHI8rhnJLR4srkOcK+/tfZJcCD53ak0sHAJokjSarpJooIDt8DPWT0y PwoPD0cA+AaPPSNJ9DYJoifOLGo4LKpiMMGBVWbnjfYg04yupDB/OSOYwHygdz0PWXj9 BksQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=Ab8e8SMdV/PMxntneBmOuTYsu5dIocv7IIIRxn/jwGU=; b=XLGuWpdaa5/V4nVep43cxuukUk6sq61B45pKtgodh9o6gznFIhGwGBxl4vAs2d9fpF ga/V/2MJDKhDMtkg9C2XLWP4UmXCmR5zaqm6vq3UO/7jmTpuZgFPE73PU1D8XUT870vL nBpasD/he6EWKjGNd3dF+bOHq5aQ8tHUtCEWqivymTKVBGhKtw0yyO4WyVnNBdBZHRJf XlnbScrxjARbusjRIEG4VFnnlNNwRNA7zPU66fZhnph8OSgeJbfwnek6QRjT7n9Bqzgp ePbHHC9ZsGkrkz4ZbnMbMgVcE6XrSl54cWAk5Os3dF22HnbfMiK37H2KRH8cgpkmRK9E ZsoA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20210112 header.b=AxOFHsoI; spf=pass (google.com: domain of linux-crypto-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-crypto-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id da3-20020a056402176300b004582354990bsi8675503edb.454.2022.10.17.16.56.34; Mon, 17 Oct 2022 16:57:06 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-crypto-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@google.com header.s=20210112 header.b=AxOFHsoI; spf=pass (google.com: domain of linux-crypto-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-crypto-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230153AbiJQXjE (ORCPT + 99 others); Mon, 17 Oct 2022 19:39:04 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:54702 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230500AbiJQXiy (ORCPT ); Mon, 17 Oct 2022 19:38:54 -0400 Received: from mail-wr1-x42c.google.com (mail-wr1-x42c.google.com [IPv6:2a00:1450:4864:20::42c]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id AFF15857FA for ; Mon, 17 Oct 2022 16:38:38 -0700 (PDT) Received: by mail-wr1-x42c.google.com with SMTP id bp11so20908933wrb.9 for ; Mon, 17 Oct 2022 16:38:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=Ab8e8SMdV/PMxntneBmOuTYsu5dIocv7IIIRxn/jwGU=; b=AxOFHsoIKvP7ysD7tzrCFiEpFNFKWLTlRj8jM8+8JPqgP6LM7SbMGw5w2QYLqfHWGq txOceHGNtwyPyi2DSDUcIRWmvm5hc4w/3f+gFwaZzRKyVD5lx7D+mcjw023+uujfBNVQ uLsRGaBA3svAV6n5xS9slXluhHbhOg8F1Ys1lsrmqw22Pz2cjJVWgeu0yGKiCqpflhhD VT9VCm2LouZBuunSikA6NEKj/WwZmLt/4y8zj9Gsty4UDYuMXwK6AOEIvDuvh+s6arl+ uQHSv0fixWyaT/IQIy4YcEOg7g4QLB1pMyh/XCa11ZHx/S9OVn1d0jjQ0+Ifskuci3fw wUDw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=Ab8e8SMdV/PMxntneBmOuTYsu5dIocv7IIIRxn/jwGU=; b=SxF1d1e+Q7xHqmKN8+FG8E32MAV4lKb4oXjYFJM8vAyzxZZyrcm7wo/nEB4szCahHn BBm7C80vY+QjldqdsGBoD2MpNJTLnS9yTkoxeU0zzfbC872Ltpj6hPsyDOCNcrBEvISw ewndccSoDFBsFxB226zGs7pt9kmS3zvfye8KdIlmsu+ed9nBcEw8M2/4aYW1XpfNJ609 nzjdremiRupR7lGjXnkKXdu+dCHIfwcNX5MqYklCzFMjuMVHvpjEbWuSs1tDkkfcJU65 vAsSw0zrcmOpxuLzY7z04/CP4/73cYu60Zw6FuBSsnZZycOT08tInDfABkDAGTM3hh/y FjpQ== X-Gm-Message-State: ACrzQf36x0Ct5EGHKjF6S2IGdfRP978Z47CQvavuPXIlr9FkfUy6ZF7V mav7mAOhNSXVdbNU/AHyYac2WAo6ryUhoEFj7Q0BYA== X-Received: by 2002:a5d:4889:0:b0:22b:214:38dd with SMTP id g9-20020a5d4889000000b0022b021438ddmr136371wrq.32.1666049917198; Mon, 17 Oct 2022 16:38:37 -0700 (PDT) MIME-Version: 1.0 References: <20221017222620.715153-1-nhuck@google.com> In-Reply-To: From: Nathan Huckleberry Date: Mon, 17 Oct 2022 16:38:25 -0700 Message-ID: Subject: Re: [PATCH] crypto: x86/polyval - Fix crashes when keys are not 16-byte aligned To: Eric Biggers Cc: Bruno Goncalves , Herbert Xu , "David S. Miller" , Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , x86@kernel.org, "H. Peter Anvin" , Ard Biesheuvel , linux-crypto@vger.kernel.org, linux-kernel@vger.kernel.org Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-17.6 required=5.0 tests=BAYES_00,DKIMWL_WL_MED, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF, ENV_AND_HDR_SPF_MATCH,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS, USER_IN_DEF_DKIM_WL,USER_IN_DEF_SPF_WL autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-crypto@vger.kernel.org On Mon, Oct 17, 2022 at 4:02 PM Eric Biggers wrote: > > On Mon, Oct 17, 2022 at 03:26:20PM -0700, Nathan Huckleberry wrote: > > The key_powers array is not guaranteed to be 16-byte aligned, so using > > movaps to operate on key_powers is not allowed. > > > > Switch movaps to movups. > > > > Fixes: 34f7f6c30112 ("crypto: x86/polyval - Add PCLMULQDQ accelerated implementation of POLYVAL") > > Reported-by: Bruno Goncalves > > Signed-off-by: Nathan Huckleberry > > --- > > arch/x86/crypto/polyval-clmulni_asm.S | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/arch/x86/crypto/polyval-clmulni_asm.S b/arch/x86/crypto/polyval-clmulni_asm.S > > index a6ebe4e7dd2b..32b98cb53ddf 100644 > > --- a/arch/x86/crypto/polyval-clmulni_asm.S > > +++ b/arch/x86/crypto/polyval-clmulni_asm.S > > @@ -234,7 +234,7 @@ > > > > movups (MSG), %xmm0 > > pxor SUM, %xmm0 > > - movaps (KEY_POWERS), %xmm1 > > + movups (KEY_POWERS), %xmm1 > > schoolbook1_noload > > dec BLOCKS_LEFT > > addq $16, MSG > > I thought that crypto_tfm::__crt_ctx is guaranteed to be 16-byte aligned, > and that the x86 AES code relies on that property. > > But now I see that actually the x86 AES code manually aligns the context. > See aes_ctx() in arch/x86/crypto/aesni-intel_glue.c. > > Did you consider doing the same for polyval? I'll submit a v2 aligning the tfm_ctx. I think that makes more sense than working on unaligned keys. Is there a need to do the same changes on arm64? The keys are also unaligned there. > > If you do prefer this way, it would be helpful to leave a comment for > schoolbook1_iteration that mentions that the unaligned access support of > vpclmulqdq is being relied on, i.e. pclmulqdq wouldn't work. > > - Eric Thanks, Huck