From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id D585C2F4317; Thu, 12 Jun 2025 00:59:16 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1749689957; cv=none; b=JSLesiVdJlQwnVtoeGrW4y0utTyRPHs4KRweGF6y4K1NrdT9j2B6dqglxwgsFX4Gp0wxZxHUtQR9DAGYYJV/dnhSgP639LK9Dl+D5orlVhe+exbJEu/FNp3/KyoThQOxVCb49hkhSTcK3TIaMeRnQCvr+t2pbVVSy8gB/coD+Pk= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1749689957; c=relaxed/simple; bh=1pLf5bk/3PFIluwpReZ5mviAqg4CGwb1cCQQmcLw6f0=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=kIUcNo8EPpZbg+GEz8duEG5ZDuJpiw5PEcQYZMWJbv066LjKHthuNCFIMrIIJWxdu9o5VayG+uEHYJuWj7NgKmEYPiAnqFat5xNmjYX+vibSCl1NyoFmA6Kpiw2qKnvBrAL+xEhEJ/eUiY3XULCBW4LvACitNM01Ikk0qSM7/yg= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=kn8RsBx4; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="kn8RsBx4" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 03066C4CEE3; Thu, 12 Jun 2025 00:59:15 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1749689956; bh=1pLf5bk/3PFIluwpReZ5mviAqg4CGwb1cCQQmcLw6f0=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=kn8RsBx4W5wwKgjX2bn2GPL7w7pbuxS4bXmDFzdgWA+KONs14NmKhmdJn+9//1d2a U2/Kgaq61LJNRw8jMvkf4uuYNdcYZYbu5E+O60TZXvsvNQ7wT7YrPZUrelkhOW+wAN Xy4kBVI1wepj/dFanHYyWK6/6/i0/d1i+/QhVo9b/rG0Xb9jNoDgkijJvYExFr7dwj Y6UevZfed66WMmM3EFdMAmC1ngqx06O96BHAbNL6wlbVp6LW3w7GkeJKZz9M+LSMyL WAnmQ488J49VwokEuqF6q/94k3A/56jKE7K5zazfC8qQE2LLdby/S/Sdex/T3xWbx8 ZwyP9Yt+uFe7A== Date: Thu, 12 Jun 2025 00:59:14 +0000 From: Eric Biggers To: Simon Richter Cc: linux-fscrypt@vger.kernel.org, linux-crypto@vger.kernel.org, linux-kernel@vger.kernel.org, linux-mtd@lists.infradead.org, linux-ext4@vger.kernel.org, linux-f2fs-devel@lists.sourceforge.net, ceph-devel@vger.kernel.org Subject: Re: [PATCH] fscrypt: don't use hardware offload Crypto API drivers Message-ID: <20250612005914.GA546455@google.com> References: <20250611205859.80819-1-ebiggers@kernel.org> <7f63be76-289b-4a99-b802-afd72e0512b8@hogyros.de> Precedence: bulk X-Mailing-List: ceph-devel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7f63be76-289b-4a99-b802-afd72e0512b8@hogyros.de> On Thu, Jun 12, 2025 at 09:21:26AM +0900, Simon Richter wrote: > Hi, > > On 6/12/25 05:58, Eric Biggers wrote: > > > But > > otherwise this style of hardware offload is basically obsolete and has > > been superseded by hardware-accelerated crypto instructions directly on > > the CPU as well as inline storage encryption (UFS/eMMC). > > For desktop, yes, but embedded still has quite a few of these, for example > the STM32 crypto offload engine, and I expect quite a few FPGA based > implementations exist, so this would require vendors to maintain a fork to > keep their out-of-tree drivers functional when updating the kernel. > > POWER also has an asynchronous offload engine with AES, SHA and gzip > support, these are significantly faster than the CPU. Do you know if anyone is actually still using a legacy-style accelerator with fscrypt, and if so what specific performance improvements are they getting? Arguing that legacy-style crypto acceleration could theoretically be useful in general isn't really relevant here. What's relevant here is whether it's actually useful and worthwhile with this specific kernel subsystem. As I mentioned, fscrypt has never been optimized for legacy-style accelerators anyway, and no one has ever tried to do so. It just hasn't been relevant. Meanwhile, the real feedback I *do* get from users is that these drivers are causing problems for users, since the Crypto API (unwisely) enables them by default and thus fscrypt uses them by default. There are people who do care about some of these drivers, but they tend to be the manufacturer of the hardware, not the users. To me it seems like more of a check-box exercise than something that is actually worth using in practice. > If a buggy engine passes self-test, can this simply be fixed by adding more > tests? :> The crypto self-tests are disabled by default, just like any other kernel subsystem. They are supposed to be run before a kernel is released, but for most of the drivers they aren't, since people don't have the hardware. Thus, a lot of drivers in-tree don't even pass the tests we do have. Some distros do enable the crypto self-tests in production kernels, but only the fast tests; the full set of tests is too slow to enable in production. But even the full tests don't properly test the hardware offload drivers, which have unique challenges that do not exist in software code. - Eric 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 lists.sourceforge.net (lists.sourceforge.net [216.105.38.7]) (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 87FE8C71136 for ; Thu, 12 Jun 2025 00:59:26 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.sourceforge.net; s=beta; h=Content-Transfer-Encoding:Content-Type:Cc: Reply-To:From:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:Subject:In-Reply-To:MIME-Version:References: Message-ID:To:Date:Sender:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=0+RSqsRY9zSeUINIWynKRgEZYyvg32U67vSIiNthevc=; b=SGN9zp4iDwg/u2DA9waviLXBGI h3ULy0iO1CAMvJ8c7cgdQ49tURQOfzEa7fArrx+rAubnfmoC1Vvy4oW3GwRbjxs5kUjZPp8HZiThH DcraYhbUY3iYGY/bUsFvk9dko3RN+8VzKg9k3C7fobNm4bz6AcATRgCa8v2YYgEzYvhw=; Received: from [127.0.0.1] (helo=sfs-ml-4.v29.lw.sourceforge.com) by sfs-ml-4.v29.lw.sourceforge.com with esmtp (Exim 4.95) (envelope-from ) id 1uPWHt-0006NG-5O; Thu, 12 Jun 2025 00:59:25 +0000 Received: from [172.30.29.66] (helo=mx.sourceforge.net) by sfs-ml-4.v29.lw.sourceforge.com with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.95) (envelope-from ) id 1uPWHr-0006N9-8G for linux-f2fs-devel@lists.sourceforge.net; Thu, 12 Jun 2025 00:59:23 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=sourceforge.net; s=x; h=In-Reply-To:Content-Type:MIME-Version:References: Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To:Content-Transfer-Encoding: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=VgdA/brGVKWRJ3BiUx7Nubq9TxbIqGAD4o6ifrXDSYk=; b=NrfFW6ETLEcvCXpybelxAHfwPB LBu/+1JRpvNUZPWM/7O4rVTEk9XNY8zsa4TRMXxzGSN/36jVP8xnNBKu0We/0DPYj69vN2a9Tw9KI hoHwVls74g0IlGX0n1p8dTSx4w+GJVa7F5/EnLCCapfYyXOS2LGeWC06KuH6oSATFfWo=; DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=sf.net; s=x ; h=In-Reply-To:Content-Type:MIME-Version:References:Message-ID:Subject:Cc:To :From:Date:Sender:Reply-To:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=VgdA/brGVKWRJ3BiUx7Nubq9TxbIqGAD4o6ifrXDSYk=; b=TO5EG7XFbeTFcO/rwuwx7WpYKP WuJVLWxMIoPou8M5ZY8PWtBFZHe1e2t3HJp36OlCEKwAEl8mXabgQv2JHCsZkmOQZ2J7ElZ4iKZyj WwTkD0p/0kMk04geOTNxayfA/CTfZCwG4j2NW/+MM5Xg3dQ0UhWF5qsjaikkfGVAv0L8=; Received: from tor.source.kernel.org ([172.105.4.254]) by sfi-mx-2.v28.lw.sourceforge.com with esmtps (TLS1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.95) id 1uPWHq-0007ng-PI for linux-f2fs-devel@lists.sourceforge.net; Thu, 12 Jun 2025 00:59:23 +0000 Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by tor.source.kernel.org (Postfix) with ESMTP id 94871629E6; Thu, 12 Jun 2025 00:59:16 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 03066C4CEE3; Thu, 12 Jun 2025 00:59:15 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1749689956; bh=1pLf5bk/3PFIluwpReZ5mviAqg4CGwb1cCQQmcLw6f0=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=kn8RsBx4W5wwKgjX2bn2GPL7w7pbuxS4bXmDFzdgWA+KONs14NmKhmdJn+9//1d2a U2/Kgaq61LJNRw8jMvkf4uuYNdcYZYbu5E+O60TZXvsvNQ7wT7YrPZUrelkhOW+wAN Xy4kBVI1wepj/dFanHYyWK6/6/i0/d1i+/QhVo9b/rG0Xb9jNoDgkijJvYExFr7dwj Y6UevZfed66WMmM3EFdMAmC1ngqx06O96BHAbNL6wlbVp6LW3w7GkeJKZz9M+LSMyL WAnmQ488J49VwokEuqF6q/94k3A/56jKE7K5zazfC8qQE2LLdby/S/Sdex/T3xWbx8 ZwyP9Yt+uFe7A== Date: Thu, 12 Jun 2025 00:59:14 +0000 To: Simon Richter Message-ID: <20250612005914.GA546455@google.com> References: <20250611205859.80819-1-ebiggers@kernel.org> <7f63be76-289b-4a99-b802-afd72e0512b8@hogyros.de> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <7f63be76-289b-4a99-b802-afd72e0512b8@hogyros.de> X-Headers-End: 1uPWHq-0007ng-PI Subject: Re: [f2fs-dev] [PATCH] fscrypt: don't use hardware offload Crypto API drivers X-BeenThere: linux-f2fs-devel@lists.sourceforge.net X-Mailman-Version: 2.1.21 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , From: Eric Biggers via Linux-f2fs-devel Reply-To: Eric Biggers Cc: linux-kernel@vger.kernel.org, linux-f2fs-devel@lists.sourceforge.net, linux-fscrypt@vger.kernel.org, linux-mtd@lists.infradead.org, linux-crypto@vger.kernel.org, ceph-devel@vger.kernel.org, linux-ext4@vger.kernel.org Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: linux-f2fs-devel-bounces@lists.sourceforge.net On Thu, Jun 12, 2025 at 09:21:26AM +0900, Simon Richter wrote: > Hi, > > On 6/12/25 05:58, Eric Biggers wrote: > > > But > > otherwise this style of hardware offload is basically obsolete and has > > been superseded by hardware-accelerated crypto instructions directly on > > the CPU as well as inline storage encryption (UFS/eMMC). > > For desktop, yes, but embedded still has quite a few of these, for example > the STM32 crypto offload engine, and I expect quite a few FPGA based > implementations exist, so this would require vendors to maintain a fork to > keep their out-of-tree drivers functional when updating the kernel. > > POWER also has an asynchronous offload engine with AES, SHA and gzip > support, these are significantly faster than the CPU. Do you know if anyone is actually still using a legacy-style accelerator with fscrypt, and if so what specific performance improvements are they getting? Arguing that legacy-style crypto acceleration could theoretically be useful in general isn't really relevant here. What's relevant here is whether it's actually useful and worthwhile with this specific kernel subsystem. As I mentioned, fscrypt has never been optimized for legacy-style accelerators anyway, and no one has ever tried to do so. It just hasn't been relevant. Meanwhile, the real feedback I *do* get from users is that these drivers are causing problems for users, since the Crypto API (unwisely) enables them by default and thus fscrypt uses them by default. There are people who do care about some of these drivers, but they tend to be the manufacturer of the hardware, not the users. To me it seems like more of a check-box exercise than something that is actually worth using in practice. > If a buggy engine passes self-test, can this simply be fixed by adding more > tests? :> The crypto self-tests are disabled by default, just like any other kernel subsystem. They are supposed to be run before a kernel is released, but for most of the drivers they aren't, since people don't have the hardware. Thus, a lot of drivers in-tree don't even pass the tests we do have. Some distros do enable the crypto self-tests in production kernels, but only the fast tests; the full set of tests is too slow to enable in production. But even the full tests don't properly test the hardware offload drivers, which have unique challenges that do not exist in software code. - Eric _______________________________________________ Linux-f2fs-devel mailing list Linux-f2fs-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel 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 88CEAC71135 for ; Thu, 12 Jun 2025 02:47:23 +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:In-Reply-To:MIME-Version:References: Message-ID:Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=1HGH7luQ5FkTvBH/om8ZiJz5JdtpSbblaihBHYIj/eA=; b=GNE7RzBKuD0HwY CR0An1YaoAEVmMJ2w99WBUYciTymSad45/S1srjs329DzFSg2XSNUcILUG+TYByC4A/gzXyiLa0PY ne9MrBrB9p97NGEDHWfioYroE6O1DH4Dorbh33huIAklNoqaHKN9NEIIkg1Il/GVCIIBFd3Bfb/nV /sSfoZSCq7JRRIKltY7g2+NehypjQ5lY18mtALFEbumxG9UMXsF34stQE0ep3hwM2jkgwwy08M1e1 aVUb7Zy18PvjYZpv/Fo4sYWdD8hqsfFww2Kmsq39jAC/e5GEJohEtTjdGb4B1mnq2SieAoQyZ6f4p Y5iIG04mM2hUuFdCr4Kw==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.98.2 #2 (Red Hat Linux)) id 1uPXyK-0000000C0jH-1zlG; Thu, 12 Jun 2025 02:47:20 +0000 Received: from tor.source.kernel.org ([172.105.4.254]) by bombadil.infradead.org with esmtps (Exim 4.98.2 #2 (Red Hat Linux)) id 1uPWHl-0000000BqX5-34MF for linux-mtd@lists.infradead.org; Thu, 12 Jun 2025 00:59:17 +0000 Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by tor.source.kernel.org (Postfix) with ESMTP id 94871629E6; Thu, 12 Jun 2025 00:59:16 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 03066C4CEE3; Thu, 12 Jun 2025 00:59:15 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1749689956; bh=1pLf5bk/3PFIluwpReZ5mviAqg4CGwb1cCQQmcLw6f0=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=kn8RsBx4W5wwKgjX2bn2GPL7w7pbuxS4bXmDFzdgWA+KONs14NmKhmdJn+9//1d2a U2/Kgaq61LJNRw8jMvkf4uuYNdcYZYbu5E+O60TZXvsvNQ7wT7YrPZUrelkhOW+wAN Xy4kBVI1wepj/dFanHYyWK6/6/i0/d1i+/QhVo9b/rG0Xb9jNoDgkijJvYExFr7dwj Y6UevZfed66WMmM3EFdMAmC1ngqx06O96BHAbNL6wlbVp6LW3w7GkeJKZz9M+LSMyL WAnmQ488J49VwokEuqF6q/94k3A/56jKE7K5zazfC8qQE2LLdby/S/Sdex/T3xWbx8 ZwyP9Yt+uFe7A== Date: Thu, 12 Jun 2025 00:59:14 +0000 From: Eric Biggers To: Simon Richter Cc: linux-fscrypt@vger.kernel.org, linux-crypto@vger.kernel.org, linux-kernel@vger.kernel.org, linux-mtd@lists.infradead.org, linux-ext4@vger.kernel.org, linux-f2fs-devel@lists.sourceforge.net, ceph-devel@vger.kernel.org Subject: Re: [PATCH] fscrypt: don't use hardware offload Crypto API drivers Message-ID: <20250612005914.GA546455@google.com> References: <20250611205859.80819-1-ebiggers@kernel.org> <7f63be76-289b-4a99-b802-afd72e0512b8@hogyros.de> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <7f63be76-289b-4a99-b802-afd72e0512b8@hogyros.de> X-BeenThere: linux-mtd@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Linux MTD discussion mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-mtd" Errors-To: linux-mtd-bounces+linux-mtd=archiver.kernel.org@lists.infradead.org On Thu, Jun 12, 2025 at 09:21:26AM +0900, Simon Richter wrote: > Hi, > > On 6/12/25 05:58, Eric Biggers wrote: > > > But > > otherwise this style of hardware offload is basically obsolete and has > > been superseded by hardware-accelerated crypto instructions directly on > > the CPU as well as inline storage encryption (UFS/eMMC). > > For desktop, yes, but embedded still has quite a few of these, for example > the STM32 crypto offload engine, and I expect quite a few FPGA based > implementations exist, so this would require vendors to maintain a fork to > keep their out-of-tree drivers functional when updating the kernel. > > POWER also has an asynchronous offload engine with AES, SHA and gzip > support, these are significantly faster than the CPU. Do you know if anyone is actually still using a legacy-style accelerator with fscrypt, and if so what specific performance improvements are they getting? Arguing that legacy-style crypto acceleration could theoretically be useful in general isn't really relevant here. What's relevant here is whether it's actually useful and worthwhile with this specific kernel subsystem. As I mentioned, fscrypt has never been optimized for legacy-style accelerators anyway, and no one has ever tried to do so. It just hasn't been relevant. Meanwhile, the real feedback I *do* get from users is that these drivers are causing problems for users, since the Crypto API (unwisely) enables them by default and thus fscrypt uses them by default. There are people who do care about some of these drivers, but they tend to be the manufacturer of the hardware, not the users. To me it seems like more of a check-box exercise than something that is actually worth using in practice. > If a buggy engine passes self-test, can this simply be fixed by adding more > tests? :> The crypto self-tests are disabled by default, just like any other kernel subsystem. They are supposed to be run before a kernel is released, but for most of the drivers they aren't, since people don't have the hardware. Thus, a lot of drivers in-tree don't even pass the tests we do have. Some distros do enable the crypto self-tests in production kernels, but only the fast tests; the full set of tests is too slow to enable in production. But even the full tests don't properly test the hardware offload drivers, which have unique challenges that do not exist in software code. - Eric ______________________________________________________ Linux MTD discussion mailing list http://lists.infradead.org/mailman/listinfo/linux-mtd/