From: Herbert Xu <herbert@gondor.apana.org.au>
To: Eric Biggers <ebiggers@kernel.org>
Cc: linux-crypto@vger.kernel.org, linux-kernel@vger.kernel.org,
dm-devel@lists.linux.dev, evepolonium@gmail.com,
shane.wang@intel.com
Subject: Re: [PATCH] crypto: vmac - remove unused VMAC algorithm
Date: Sat, 4 Jan 2025 09:18:17 +0800 [thread overview]
Message-ID: <Z3iMWXwCLg36eous@gondor.apana.org.au> (raw)
In-Reply-To: <20241226194309.27733-1-ebiggers@kernel.org>
Eric Biggers <ebiggers@kernel.org> wrote:
> From: Eric Biggers <ebiggers@google.com>
>
> Remove the vmac64 template, as it has no known users. It also continues
> to have longstanding bugs such as alignment violations (see
> https://lore.kernel.org/r/20241226134847.6690-1-evepolonium@gmail.com/).
>
> This code was added in 2009 by commit f1939f7c5645 ("crypto: vmac - New
> hash algorithm for intel_txt support"). Based on the mention of
> intel_txt support in the commit title, it seems it was added as a
> prerequisite for the contemporaneous patch
> "intel_txt: add s3 userspace memory integrity verification"
> (https://lore.kernel.org/r/4ABF2B50.6070106@intel.com/). In the design
> proposed by that patch, when an Intel Trusted Execution Technology (TXT)
> enabled system resumed from suspend, the "tboot" trusted executable
> launched the Linux kernel without verifying userspace memory, and then
> the Linux kernel used VMAC to verify userspace memory.
>
> However, that patch was never merged, as reviewers had objected to the
> design. It was later reworked into commit 4bd96a7a8185 ("x86, tboot:
> Add support for S3 memory integrity protection") which made tboot verify
> the memory instead. Thus the VMAC support in Linux was never used.
>
> No in-tree user has appeared since then, other than potentially the
> usual components that allow specifying arbitrary hash algorithms by
> name, namely AF_ALG and dm-integrity. However there are no indications
> that VMAC is being used with these components. Debian Code Search and
> web searches for "vmac64" (the actual algorithm name) do not return any
> results other than the kernel itself, suggesting that it does not appear
> in any other code or documentation. Explicitly grepping the source code
> of the usual suspects (libell, iwd, cryptsetup) finds no matches either.
>
> Before 2018, the vmac code was also completely broken due to using a
> hardcoded nonce and the wrong endianness for the MAC. It was then fixed
> by commit ed331adab35b ("crypto: vmac - add nonced version with big
> endian digest") and commit 0917b873127c ("crypto: vmac - remove insecure
> version with hardcoded nonce"). These were intentionally breaking
> changes that changed all the computed MAC values as well as the
> algorithm name ("vmac" to "vmac64"). No complaints were ever received
> about these breaking changes, strongly suggesting the absence of users.
>
> The reason I had put some effort into fixing this code in 2018 is
> because it was used by an out-of-tree driver. But if it is still needed
> in that particular out-of-tree driver, the code can be carried in that
> driver instead. There is no need to carry it upstream.
>
> Cc: Atharva Tiwari <evepolonium@gmail.com>
> Cc: Shane Wang <shane.wang@intel.com>
> Signed-off-by: Eric Biggers <ebiggers@google.com>
> ---
> arch/arm/configs/pxa_defconfig | 1 -
> arch/loongarch/configs/loongson3_defconfig | 1 -
> arch/m68k/configs/amiga_defconfig | 1 -
> arch/m68k/configs/apollo_defconfig | 1 -
> arch/m68k/configs/atari_defconfig | 1 -
> arch/m68k/configs/bvme6000_defconfig | 1 -
> arch/m68k/configs/hp300_defconfig | 1 -
> arch/m68k/configs/mac_defconfig | 1 -
> arch/m68k/configs/multi_defconfig | 1 -
> arch/m68k/configs/mvme147_defconfig | 1 -
> arch/m68k/configs/mvme16x_defconfig | 1 -
> arch/m68k/configs/q40_defconfig | 1 -
> arch/m68k/configs/sun3_defconfig | 1 -
> arch/m68k/configs/sun3x_defconfig | 1 -
> arch/mips/configs/bigsur_defconfig | 1 -
> arch/mips/configs/decstation_64_defconfig | 1 -
> arch/mips/configs/decstation_defconfig | 1 -
> arch/mips/configs/decstation_r4k_defconfig | 1 -
> arch/mips/configs/ip27_defconfig | 1 -
> arch/mips/configs/ip30_defconfig | 1 -
> arch/s390/configs/debug_defconfig | 1 -
> arch/s390/configs/defconfig | 1 -
> crypto/Kconfig | 10 -
> crypto/Makefile | 1 -
> crypto/tcrypt.c | 4 -
> crypto/testmgr.c | 6 -
> crypto/testmgr.h | 153 -----
> crypto/vmac.c | 696 ---------------------
> 28 files changed, 892 deletions(-)
> delete mode 100644 crypto/vmac.c
Patch applied. Thanks.
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
prev parent reply other threads:[~2025-01-04 1:18 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-12-26 19:43 [PATCH] crypto: vmac - remove unused VMAC algorithm Eric Biggers
2024-12-27 8:43 ` Ard Biesheuvel
2024-12-30 11:05 ` Geert Uytterhoeven
2025-01-02 8:49 ` Milan Broz
2025-01-04 1:18 ` Herbert Xu [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Z3iMWXwCLg36eous@gondor.apana.org.au \
--to=herbert@gondor.apana.org.au \
--cc=dm-devel@lists.linux.dev \
--cc=ebiggers@kernel.org \
--cc=evepolonium@gmail.com \
--cc=linux-crypto@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=shane.wang@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox