public inbox for linux-crypto@vger.kernel.org
 help / color / mirror / Atom feed
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

      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