lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CAMj1kXEufcfUMoNW3M4T2CvnvJP4NyNF=YRAj8vh_pSyVywJ2g@mail.gmail.com>
Date: Fri, 27 Dec 2024 09:43:01 +0100
From: Ard Biesheuvel <ardb@...nel.org>
To: Eric Biggers <ebiggers@...nel.org>
Cc: linux-crypto@...r.kernel.org, linux-kernel@...r.kernel.org, 
	dm-devel@...ts.linux.dev, Atharva Tiwari <evepolonium@...il.com>, 
	Shane Wang <shane.wang@...el.com>
Subject: Re: [PATCH] crypto: vmac - remove unused VMAC algorithm

On Thu, 26 Dec 2024 at 20:44, Eric Biggers <ebiggers@...nel.org> wrote:
>
> From: Eric Biggers <ebiggers@...gle.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@...il.com>
> Cc: Shane Wang <shane.wang@...el.com>
> Signed-off-by: Eric Biggers <ebiggers@...gle.com>

Acked-by: Ard Biesheuvel <ardb@...nel.org>

> ---
>  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
>
...

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ