On Thu, Dec 26, 2024 at 8:44 PM 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> > 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 - Acked-by: Geert Uytterhoeven <geert@xxxxxxxxxxxxxx> # m68k Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@xxxxxxxxxxxxxx In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds
