On Thu, 26 Dec 2024 at 20:44, Eric Biggers <ebiggers@xxxxxxxxxx> wrote: > > From: Eric Biggers <ebiggers@xxxxxxxxxx> > > 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@xxxxxxxxx/). > > 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@xxxxxxxxx/). 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@xxxxxxxxx> > Cc: Shane Wang <shane.wang@xxxxxxxxx> > Signed-off-by: Eric Biggers <ebiggers@xxxxxxxxxx> Acked-by: Ard Biesheuvel <ardb@xxxxxxxxxx> > --- > 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 > ...
