Received: by 2002:a05:6a10:af89:0:0:0:0 with SMTP id iu9csp1161279pxb; Fri, 21 Jan 2022 11:09:06 -0800 (PST) X-Google-Smtp-Source: ABdhPJwUtfwpYmDved2xSd5oAlx0eRkxH4YmYAG+26UGlgmjCTJ4dc3fG5+EIpIuQGU+sp+Jshvg X-Received: by 2002:a05:6a00:1d0f:b0:4c7:4bbe:b540 with SMTP id a15-20020a056a001d0f00b004c74bbeb540mr3846373pfx.4.1642792145842; Fri, 21 Jan 2022 11:09:05 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1642792145; cv=none; d=google.com; s=arc-20160816; b=oD7zv2U8DZQbU8wzUJDUo+1eVIFmLZMOqDKcOiWt/I3HPQGdYF+Madv6fK9YmpWFDx F6VPBdpIkOPuiEQlVqObOcaULXYUylU94TysRXBr8hNc/DoWxwQldAZ4tInOu0v37LK/ D+Zfc6BeEydP8leapxX3d0rQYEmx7WpMclvZq0UlrgNL+W3vOWfdIJ9fNvcOQ8AnJDpi lxuyLy2z2G3HCbBSMknzDmRaBqz8/9t4VM6yqrxdF3EOFKH5EW5Wdj98p1PyMklcgu/+ rFntNwNok4WBbbRHOuRJnxizWpLp1mUxxxWVxgZujMoBKZ6TywiGnjf1h74adsnLEMxw rvmg== 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=WOjPOKHegIereh6b+hesSlN0hLrkmBrVMNuDP6Ywag4=; b=iAMKUjwQBhtwLedbfhOOuxAx0F84kJizmJ2lbojRgzZm/ByCu8clhYbYV9eBHothdn pHauepy57xdq0U2+UFYb3GSbHFbKs/EVwrb5oA8fufm4g7y5exhGSeMalh1lRIjOy3ih c/gaAtJM1kgIv6IMyYjNK4E6b1uzFo7Pnil8UTUYGbIB69l5bO5sedrfC4Tda3mSAzYd /YftvhsqJ9xmw1/D4+5AGR78bEtP3BNlc6tTzVSD/KOEeledng0QC04kgNT42nuvynKs TXVmfxMnJICFq4VkVDPC9rGF/M2ymNenHfUF0S0wJV2nxw08/2gjzkb+8jSwKvHLzLjn YZyQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=OY+FuNZs; spf=pass (google.com: domain of linux-crypto-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-crypto-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id s6si751656plg.242.2022.01.21.11.08.53; Fri, 21 Jan 2022 11:09:05 -0800 (PST) Received-SPF: pass (google.com: domain of linux-crypto-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=OY+FuNZs; spf=pass (google.com: domain of linux-crypto-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-crypto-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1348072AbiASKfs (ORCPT + 99 others); Wed, 19 Jan 2022 05:35:48 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:48224 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1343802AbiASKfr (ORCPT ); Wed, 19 Jan 2022 05:35:47 -0500 Received: from ams.source.kernel.org (ams.source.kernel.org [IPv6:2604:1380:4601:e00::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 55BF4C061574; Wed, 19 Jan 2022 02:35:47 -0800 (PST) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id 210AAB81981; Wed, 19 Jan 2022 10:35:46 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id E9C6CC340EC; Wed, 19 Jan 2022 10:35:44 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1642588544; bh=dLVBsjWsa3tGe7VI+gEjPAK21hcD2zsUppaxNspCidw=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=OY+FuNZsU4FCGv13S5pE17km9nFJ1sREVRgpDGQ3pF1hqIWYJj8cI5XCxXu372wy/ x8qRQrobeWclhryEaq/pzYK0MrdOCEu9NcYrJ29i4IpnUqbQXN5oZ/Ibd1wYTh7Icr fIDmXjiYEcnQ4R5kQzKQWcrgUtdgL4TMU28ukJlmRMrmncy5mtPeWwlStAI7Z06KbW tQJpb54LWKlSp0sliFIzFwuiS98/B9vCwQaZtKuYxBKehYH5lDeD2kdFGSgM2bLL+H iYtuj0ZJhGM5vIlNeKiRPtvNK1JnwxlfhAVe7PRK4OZ9279oqgJmf5WHeBjEgVYksT olvWSmwJx5vpg== Received: by mail-wm1-f43.google.com with SMTP id l12-20020a7bc34c000000b003467c58cbdfso13417779wmj.2; Wed, 19 Jan 2022 02:35:44 -0800 (PST) X-Gm-Message-State: AOAM533KlsqsgcWikPieGJL2/nY1iuRJFxmdcWJBlFX3W58bSIP2WBtZ ahm+KhqtcegR1kUDPpoUgKehHFjUFtOAWngRa7E= X-Received: by 2002:a05:600c:3c9c:: with SMTP id bg28mr2778170wmb.190.1642588543206; Wed, 19 Jan 2022 02:35:43 -0800 (PST) MIME-Version: 1.0 References: <20220119100615.5059-1-miles.chen@mediatek.com> In-Reply-To: From: Ard Biesheuvel Date: Wed, 19 Jan 2022 11:35:32 +0100 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH] lib/crypto: blake2s: fix a CFI failure To: "Jason A. Donenfeld" Cc: Miles Chen , "David S. Miller" , Greg Kroah-Hartman , Herbert Xu , Linux ARM , Linux Crypto Mailing List , Linux Kernel Mailing List , linux-mediatek@lists.infradead.org, Matthias Brugger , Nathan Chancellor , Nick Desaulniers Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-crypto@vger.kernel.org On Wed, 19 Jan 2022 at 11:20, Jason A. Donenfeld wrote: > > On 1/19/22, Ard Biesheuvel wrote: > > On Wed, 19 Jan 2022 at 11:06, Miles Chen wrote: > >> > >> Hi, > >> > >> >Hi Miles, > >> > > >> >I'm actually not able to reproduce your oops. I'm using vanilla clang > >> >13, cross compiling for arm64, with thin LTO enabled and CFI enabled. > >> >Kernel seems to run fine. > >> > > >> > > >> >Are there other settings that are needed to trigger this? Do you see > >> >it in upstream clang or just the Android fork of clang? > >> > > >> I will try another clang (the previous version I use). > >> I am using Android fork of clang and there is a clang upgrade in this > >> merge. > >> > > > > One thing that could be worth a try is to make __blake2s_update() and > > __blake2s_final() __always_inline rather than just inline, which by > > itself does not appear to be sufficient for the code to get inlined. > > (If it were, the indirect call should have disappeared as well) > > > > Given that indirect calls suck on x86, we should probably apply that > > change in any case, regardless of CFI. > > > > Had the same thought at first, but then looking at the original stack > trace, it looks like the __ function is inlined: > > [ 0.000000][ T0] __cfi_slowpath_diag+0x354/0x4b0 > [ 0.000000][ T0] blake2s_update+0x14c/0x178 > [ 0.000000][ T0] _extract_entropy+0xf4/0x29c > Indeed. How odd. I hope this doesn't happen with the x86 backend because that would be plain silly. On arm64, it doesn't actually matter in terms of performance, it just needs one additional callee save register to preserve the function pointer across calls.