From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id C01FAC433F5 for ; Wed, 19 Jan 2022 10:35:48 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1348072AbiASKfs (ORCPT ); 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-Google-Smtp-Source: ABdhPJxz62Vu1t8USPQKfzN9UxWCuXzIdAWIMYfTvzG08o48WSftiicOZMHsxR2P9Zuf5cNWB4skcW66Hpc+FiM5xGo= 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. From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id A1B9BC433F5 for ; Wed, 19 Jan 2022 10:36:08 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:Cc:To:Subject:Message-ID:Date:From: In-Reply-To:References:MIME-Version:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=xzbvod72kppoY0rdLL1IKREaL9vXGHoIPxjXx9iU3Lo=; b=wZdFyzEffvcREa jGLq9SyzDrufzUZQXIhiiWO4Jw4ogejyYFHSnzKkoTz91kBycSZiPTzkfXKhu1750D/HMJpyKxyjn XPuksxrDy62Ydiv1s8YDBWBsRIJCrg1PSvbNGNVCaBxJ4DBtcpoldrkYl8EvLyLGX32qptNP07jVl 91w4mwWVfheECJwXLv3GTypSXBZJOHLHR/IA+g+Wyo0ibqznxqRzKeStE7Ywe+w1AmcfO8VheuCfv 57ThIWxmzm1ET5p0aF4P/B60jJ08S3YmPWs4/8AFfG4AvGdDMeYO+CKGG9Ajh+VrngNPWwIJBPrF9 INaZZrjnpEol7iU98R6g==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1nA8Jt-004xPw-3t; Wed, 19 Jan 2022 10:36:01 +0000 Received: from dfw.source.kernel.org ([2604:1380:4641:c500::1]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1nA8Jd-004xJw-TT; Wed, 19 Jan 2022 10:35:48 +0000 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 dfw.source.kernel.org (Postfix) with ESMTPS id 6EF0D61599; Wed, 19 Jan 2022 10:35:45 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id D6625C36AE3; 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-f46.google.com with SMTP id q141-20020a1ca793000000b00347b48dfb53so5046761wme.0; Wed, 19 Jan 2022 02:35:44 -0800 (PST) X-Gm-Message-State: AOAM532JGO/WbU0DggVjKpLwV6cl0DH0/zZw4YRHrH5zcWIm3Q2Sgyzx TjGR6p3QPNjBB38tCrTD4Gpx/Zra+M1YcQdmwp4= X-Google-Smtp-Source: ABdhPJxz62Vu1t8USPQKfzN9UxWCuXzIdAWIMYfTvzG08o48WSftiicOZMHsxR2P9Zuf5cNWB4skcW66Hpc+FiM5xGo= 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 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220119_023546_054926_817A40B0 X-CRM114-Status: GOOD ( 28.39 ) X-BeenThere: linux-mediatek@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "Linux-mediatek" Errors-To: linux-mediatek-bounces+linux-mediatek=archiver.kernel.org@lists.infradead.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. _______________________________________________ Linux-mediatek mailing list Linux-mediatek@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-mediatek From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 58D72C433EF for ; Wed, 19 Jan 2022 10:37:08 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:Cc:To:Subject:Message-ID:Date:From: In-Reply-To:References:MIME-Version:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=BYHqwhbaQxvFIq+3771mU9mdJ6hhLBj0R6CwMMNlPWQ=; b=4x3/wRwIDyfqBK qpfS5mTWujHQ/Z52UI7l4AfGSqXlR5vDoEd5S4k2t2hPgpe7HachnOLk6ANv9VRdsXyLBtMguV+RO uTjSNHqMSalx6Y9zSAGb7WW+EMVcIY1Zquw1MNNjm5oIs/O9wzByHi33pnWeOk3L6tHwDN19RQ52V 5EomwKs6uQ9Uek9PcLGJ5mu65cmqwuiI/LTmBYQnf++KuPLvcszgLLIrex8IAiVUa/j47EGvXcHjX La0wyXUnrA6vtbi4rqA+o05giRHa5ZDesC07l/8okhu6mIoFQ7TGUKXnIKEio5oJmeWTa45KHwER5 WZQHhhthdaKUvJzMNyIw==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1nA8Jj-004xLp-FY; Wed, 19 Jan 2022 10:35:51 +0000 Received: from dfw.source.kernel.org ([2604:1380:4641:c500::1]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1nA8Jd-004xJw-TT; Wed, 19 Jan 2022 10:35:48 +0000 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 dfw.source.kernel.org (Postfix) with ESMTPS id 6EF0D61599; Wed, 19 Jan 2022 10:35:45 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id D6625C36AE3; 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-f46.google.com with SMTP id q141-20020a1ca793000000b00347b48dfb53so5046761wme.0; Wed, 19 Jan 2022 02:35:44 -0800 (PST) X-Gm-Message-State: AOAM532JGO/WbU0DggVjKpLwV6cl0DH0/zZw4YRHrH5zcWIm3Q2Sgyzx TjGR6p3QPNjBB38tCrTD4Gpx/Zra+M1YcQdmwp4= X-Google-Smtp-Source: ABdhPJxz62Vu1t8USPQKfzN9UxWCuXzIdAWIMYfTvzG08o48WSftiicOZMHsxR2P9Zuf5cNWB4skcW66Hpc+FiM5xGo= 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 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220119_023546_054926_817A40B0 X-CRM114-Status: GOOD ( 28.39 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.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. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel