Skip to contentSkip to conversation

crypto: vmac - remove unused VMAC algorithm

PATCH In review Eric Biggers 5 participants 5 messages Dec 26, 2024 – Jan 4, 2025

Subsystems (8)
Arm (32-bit) MIPS Crypto API s390 +4 more subsystems
lore
Share & tools
lore
#0 lore raw

PATCH 1/1 crypto: vmac - remove unused VMAC algorithm

From: Eric Biggers <[email protected]>

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/[email protected]/).

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/[email protected]/). 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 <[email protected]>
Cc Shane Wang <[email protected]>
---
 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
arch/arm/configs/pxa_defconfig +0 -1
index 38916ac4bce4..de0ac8f521d7 100644
@@ -650,11 +650,10 @@ CONFIG_CRYPTO_SERPENT=m
 CONFIG_CRYPTO_TEA=m
 CONFIG_CRYPTO_TWOFISH=m
 CONFIG_CRYPTO_LRW=m
 CONFIG_CRYPTO_PCBC=m
 CONFIG_CRYPTO_XTS=m
-CONFIG_CRYPTO_VMAC=m
 CONFIG_CRYPTO_SHA512=m
 CONFIG_CRYPTO_TGR192=m
 CONFIG_CRYPTO_WP512=m
 CONFIG_CRYPTO_ANUBIS=m
 CONFIG_CRYPTO_XCBC=m
arch/loongarch/configs/loongson3_defconfig +0 -1
index 4dffc90192f7..6965b009e9a2 100644
@@ -1027,11 +1027,10 @@ CONFIG_CRYPTO_KHAZAD=m
 CONFIG_CRYPTO_SEED=m
 CONFIG_CRYPTO_SERPENT=m
 CONFIG_CRYPTO_TEA=m
 CONFIG_CRYPTO_TWOFISH=m
 CONFIG_CRYPTO_CHACHA20POLY1305=m
-CONFIG_CRYPTO_VMAC=m
 CONFIG_CRYPTO_WP512=m
 CONFIG_CRYPTO_DEFLATE=m
 CONFIG_CRYPTO_LZO=m
 CONFIG_CRYPTO_842=m
 CONFIG_CRYPTO_LZ4=m
arch/m68k/configs/amiga_defconfig +0 -1
index c705247e7b5b..5f9117b46867 100644
@@ -587,11 +587,10 @@ CONFIG_CRYPTO_AEGIS128=m
 CONFIG_CRYPTO_CHACHA20POLY1305=m
 CONFIG_CRYPTO_MD4=m
 CONFIG_CRYPTO_MICHAEL_MIC=m
 CONFIG_CRYPTO_RMD160=m
 CONFIG_CRYPTO_SM3_GENERIC=m
-CONFIG_CRYPTO_VMAC=m
 CONFIG_CRYPTO_WP512=m
 CONFIG_CRYPTO_XCBC=m
 CONFIG_CRYPTO_LZO=m
 CONFIG_CRYPTO_842=m
 CONFIG_CRYPTO_LZ4=m
arch/m68k/configs/apollo_defconfig +0 -1
index 6d62b9187a58..eb8a0432f1fa 100644
@@ -544,11 +544,10 @@ CONFIG_CRYPTO_AEGIS128=m
 CONFIG_CRYPTO_CHACHA20POLY1305=m
 CONFIG_CRYPTO_MD4=m
 CONFIG_CRYPTO_MICHAEL_MIC=m
 CONFIG_CRYPTO_RMD160=m
 CONFIG_CRYPTO_SM3_GENERIC=m
-CONFIG_CRYPTO_VMAC=m
 CONFIG_CRYPTO_WP512=m
 CONFIG_CRYPTO_XCBC=m
 CONFIG_CRYPTO_LZO=m
 CONFIG_CRYPTO_842=m
 CONFIG_CRYPTO_LZ4=m
arch/m68k/configs/atari_defconfig +0 -1
index c3c644df852d..8ac95c1207b1 100644
@@ -564,11 +564,10 @@ CONFIG_CRYPTO_AEGIS128=m
 CONFIG_CRYPTO_CHACHA20POLY1305=m
 CONFIG_CRYPTO_MD4=m
 CONFIG_CRYPTO_MICHAEL_MIC=m
 CONFIG_CRYPTO_RMD160=m
 CONFIG_CRYPTO_SM3_GENERIC=m
-CONFIG_CRYPTO_VMAC=m
 CONFIG_CRYPTO_WP512=m
 CONFIG_CRYPTO_XCBC=m
 CONFIG_CRYPTO_LZO=m
 CONFIG_CRYPTO_842=m
 CONFIG_CRYPTO_LZ4=m
arch/m68k/configs/bvme6000_defconfig +0 -1
index 20261f819691..cf9ea62bdcbe 100644
@@ -536,11 +536,10 @@ CONFIG_CRYPTO_AEGIS128=m
 CONFIG_CRYPTO_CHACHA20POLY1305=m
 CONFIG_CRYPTO_MD4=m
 CONFIG_CRYPTO_MICHAEL_MIC=m
 CONFIG_CRYPTO_RMD160=m
 CONFIG_CRYPTO_SM3_GENERIC=m
-CONFIG_CRYPTO_VMAC=m
 CONFIG_CRYPTO_WP512=m
 CONFIG_CRYPTO_XCBC=m
 CONFIG_CRYPTO_LZO=m
 CONFIG_CRYPTO_842=m
 CONFIG_CRYPTO_LZ4=m
arch/m68k/configs/hp300_defconfig +0 -1
index ce4fe93a0f70..aacb040b741e 100644
@@ -546,11 +546,10 @@ CONFIG_CRYPTO_AEGIS128=m
 CONFIG_CRYPTO_CHACHA20POLY1305=m
 CONFIG_CRYPTO_MD4=m
 CONFIG_CRYPTO_MICHAEL_MIC=m
 CONFIG_CRYPTO_RMD160=m
 CONFIG_CRYPTO_SM3_GENERIC=m
-CONFIG_CRYPTO_VMAC=m
 CONFIG_CRYPTO_WP512=m
 CONFIG_CRYPTO_XCBC=m
 CONFIG_CRYPTO_LZO=m
 CONFIG_CRYPTO_842=m
 CONFIG_CRYPTO_LZ4=m
arch/m68k/configs/mac_defconfig +0 -1
index 040ae75f47c3..2b0383580564 100644
@@ -563,11 +563,10 @@ CONFIG_CRYPTO_AEGIS128=m
 CONFIG_CRYPTO_CHACHA20POLY1305=m
 CONFIG_CRYPTO_MD4=m
 CONFIG_CRYPTO_MICHAEL_MIC=m
 CONFIG_CRYPTO_RMD160=m
 CONFIG_CRYPTO_SM3_GENERIC=m
-CONFIG_CRYPTO_VMAC=m
 CONFIG_CRYPTO_WP512=m
 CONFIG_CRYPTO_XCBC=m
 CONFIG_CRYPTO_LZO=m
 CONFIG_CRYPTO_842=m
 CONFIG_CRYPTO_LZ4=m
arch/m68k/configs/multi_defconfig +0 -1
index 20d877cb4e30..3d0b5af6bb60 100644
@@ -650,11 +650,10 @@ CONFIG_CRYPTO_AEGIS128=m
 CONFIG_CRYPTO_CHACHA20POLY1305=m
 CONFIG_CRYPTO_MD4=m
 CONFIG_CRYPTO_MICHAEL_MIC=m
 CONFIG_CRYPTO_RMD160=m
 CONFIG_CRYPTO_SM3_GENERIC=m
-CONFIG_CRYPTO_VMAC=m
 CONFIG_CRYPTO_WP512=m
 CONFIG_CRYPTO_XCBC=m
 CONFIG_CRYPTO_LZO=m
 CONFIG_CRYPTO_842=m
 CONFIG_CRYPTO_LZ4=m
arch/m68k/configs/mvme147_defconfig +0 -1
index 5e1c8d0d3da5..ee0f2fbd7fbf 100644
@@ -536,11 +536,10 @@ CONFIG_CRYPTO_AEGIS128=m
 CONFIG_CRYPTO_CHACHA20POLY1305=m
 CONFIG_CRYPTO_MD4=m
 CONFIG_CRYPTO_MICHAEL_MIC=m
 CONFIG_CRYPTO_RMD160=m
 CONFIG_CRYPTO_SM3_GENERIC=m
-CONFIG_CRYPTO_VMAC=m
 CONFIG_CRYPTO_WP512=m
 CONFIG_CRYPTO_XCBC=m
 CONFIG_CRYPTO_LZO=m
 CONFIG_CRYPTO_842=m
 CONFIG_CRYPTO_LZ4=m
arch/m68k/configs/mvme16x_defconfig +0 -1
index 5d1409e6a137..cac90de4f3e7 100644
@@ -537,11 +537,10 @@ CONFIG_CRYPTO_AEGIS128=m
 CONFIG_CRYPTO_CHACHA20POLY1305=m
 CONFIG_CRYPTO_MD4=m
 CONFIG_CRYPTO_MICHAEL_MIC=m
 CONFIG_CRYPTO_RMD160=m
 CONFIG_CRYPTO_SM3_GENERIC=m
-CONFIG_CRYPTO_VMAC=m
 CONFIG_CRYPTO_WP512=m
 CONFIG_CRYPTO_XCBC=m
 CONFIG_CRYPTO_LZO=m
 CONFIG_CRYPTO_842=m
 CONFIG_CRYPTO_LZ4=m
arch/m68k/configs/q40_defconfig +0 -1
index e4c30e2b9bbb..5301fc6fbd37 100644
@@ -553,11 +553,10 @@ CONFIG_CRYPTO_AEGIS128=m
 CONFIG_CRYPTO_CHACHA20POLY1305=m
 CONFIG_CRYPTO_MD4=m
 CONFIG_CRYPTO_MICHAEL_MIC=m
 CONFIG_CRYPTO_RMD160=m
 CONFIG_CRYPTO_SM3_GENERIC=m
-CONFIG_CRYPTO_VMAC=m
 CONFIG_CRYPTO_WP512=m
 CONFIG_CRYPTO_XCBC=m
 CONFIG_CRYPTO_LZO=m
 CONFIG_CRYPTO_842=m
 CONFIG_CRYPTO_LZ4=m
arch/m68k/configs/sun3_defconfig +0 -1
index 980843a9ea1e..1002082c0b5e 100644
@@ -534,11 +534,10 @@ CONFIG_CRYPTO_AEGIS128=m
 CONFIG_CRYPTO_CHACHA20POLY1305=m
 CONFIG_CRYPTO_MD4=m
 CONFIG_CRYPTO_MICHAEL_MIC=m
 CONFIG_CRYPTO_RMD160=m
 CONFIG_CRYPTO_SM3_GENERIC=m
-CONFIG_CRYPTO_VMAC=m
 CONFIG_CRYPTO_WP512=m
 CONFIG_CRYPTO_XCBC=m
 CONFIG_CRYPTO_LZO=m
 CONFIG_CRYPTO_842=m
 CONFIG_CRYPTO_LZ4=m
arch/m68k/configs/sun3x_defconfig +0 -1
index 38681cc6b598..65c80b7188fd 100644
@@ -534,11 +534,10 @@ CONFIG_CRYPTO_AEGIS128=m
 CONFIG_CRYPTO_CHACHA20POLY1305=m
 CONFIG_CRYPTO_MD4=m
 CONFIG_CRYPTO_MICHAEL_MIC=m
 CONFIG_CRYPTO_RMD160=m
 CONFIG_CRYPTO_SM3_GENERIC=m
-CONFIG_CRYPTO_VMAC=m
 CONFIG_CRYPTO_WP512=m
 CONFIG_CRYPTO_XCBC=m
 CONFIG_CRYPTO_LZO=m
 CONFIG_CRYPTO_842=m
 CONFIG_CRYPTO_LZ4=m
arch/mips/configs/bigsur_defconfig +0 -1
index e463a9acae03..f7c4b3529a2c 100644
@@ -220,11 +220,10 @@ CONFIG_CRYPTO_CTS=m
 CONFIG_CRYPTO_LRW=m
 CONFIG_CRYPTO_PCBC=m
 CONFIG_CRYPTO_XTS=m
 CONFIG_CRYPTO_HMAC=y
 CONFIG_CRYPTO_XCBC=m
-CONFIG_CRYPTO_VMAC=m
 CONFIG_CRYPTO_MD4=m
 CONFIG_CRYPTO_MICHAEL_MIC=m
 CONFIG_CRYPTO_RMD160=m
 CONFIG_CRYPTO_SHA512=m
 CONFIG_CRYPTO_WP512=m
arch/mips/configs/decstation_64_defconfig +0 -1
index 92a1d0aea38c..62b82ac05cf8 100644
@@ -178,11 +178,10 @@ CONFIG_CRYPTO_OFB=m
 CONFIG_CRYPTO_PCBC=m
 CONFIG_CRYPTO_XTS=m
 CONFIG_CRYPTO_KEYWRAP=m
 CONFIG_CRYPTO_CMAC=m
 CONFIG_CRYPTO_XCBC=m
-CONFIG_CRYPTO_VMAC=m
 CONFIG_CRYPTO_CRC32=m
 CONFIG_CRYPTO_CRCT10DIF=m
 CONFIG_CRYPTO_MD4=m
 CONFIG_CRYPTO_MICHAEL_MIC=m
 CONFIG_CRYPTO_RMD160=m
arch/mips/configs/decstation_defconfig +0 -1
index db214fcebcbe..46dc33484660 100644
@@ -173,11 +173,10 @@ CONFIG_CRYPTO_OFB=m
 CONFIG_CRYPTO_PCBC=m
 CONFIG_CRYPTO_XTS=m
 CONFIG_CRYPTO_KEYWRAP=m
 CONFIG_CRYPTO_CMAC=m
 CONFIG_CRYPTO_XCBC=m
-CONFIG_CRYPTO_VMAC=m
 CONFIG_CRYPTO_CRC32=m
 CONFIG_CRYPTO_CRCT10DIF=m
 CONFIG_CRYPTO_MD4=m
 CONFIG_CRYPTO_MICHAEL_MIC=m
 CONFIG_CRYPTO_RMD160=m
arch/mips/configs/decstation_r4k_defconfig +0 -1
index 15b769e96d5b..beec4fdb8fc6 100644
@@ -173,11 +173,10 @@ CONFIG_CRYPTO_OFB=m
 CONFIG_CRYPTO_PCBC=m
 CONFIG_CRYPTO_XTS=m
 CONFIG_CRYPTO_KEYWRAP=m
 CONFIG_CRYPTO_CMAC=m
 CONFIG_CRYPTO_XCBC=m
-CONFIG_CRYPTO_VMAC=m
 CONFIG_CRYPTO_CRC32=m
 CONFIG_CRYPTO_CRCT10DIF=m
 CONFIG_CRYPTO_MD4=m
 CONFIG_CRYPTO_MICHAEL_MIC=m
 CONFIG_CRYPTO_RMD160=m
arch/mips/configs/ip27_defconfig +0 -1
index 4714074c8bd7..b08a199767d1 100644
@@ -303,11 +303,10 @@ CONFIG_CRYPTO_CTS=m
 CONFIG_CRYPTO_LRW=m
 CONFIG_CRYPTO_PCBC=m
 CONFIG_CRYPTO_XTS=m
 CONFIG_CRYPTO_HMAC=y
 CONFIG_CRYPTO_XCBC=m
-CONFIG_CRYPTO_VMAC=m
 CONFIG_CRYPTO_MD4=m
 CONFIG_CRYPTO_RMD160=m
 CONFIG_CRYPTO_SHA512=m
 CONFIG_CRYPTO_WP512=m
 CONFIG_CRYPTO_ANUBIS=m
arch/mips/configs/ip30_defconfig +0 -1
index 178d61645cea..270181a7320a 100644
@@ -174,10 +174,9 @@ CONFIG_CRYPTO_LRW=m
 CONFIG_CRYPTO_PCBC=m
 CONFIG_CRYPTO_XTS=m
 CONFIG_CRYPTO_HMAC=y
 CONFIG_CRYPTO_MD4=m
 CONFIG_CRYPTO_RMD160=m
-CONFIG_CRYPTO_VMAC=m
 CONFIG_CRYPTO_WP512=m
 CONFIG_CRYPTO_XCBC=m
 CONFIG_CRYPTO_LZO=m
 CONFIG_CRC_T10DIF=m
arch/s390/configs/debug_defconfig +0 -1
index d8d227ab82de..885e73955d6a 100644
@@ -780,11 +780,10 @@ CONFIG_CRYPTO_SEQIV=y
 CONFIG_CRYPTO_MD4=m
 CONFIG_CRYPTO_MD5=y
 CONFIG_CRYPTO_MICHAEL_MIC=m
 CONFIG_CRYPTO_RMD160=m
 CONFIG_CRYPTO_SM3_GENERIC=m
-CONFIG_CRYPTO_VMAC=m
 CONFIG_CRYPTO_WP512=m
 CONFIG_CRYPTO_XCBC=m
 CONFIG_CRYPTO_CRC32=m
 CONFIG_CRYPTO_842=m
 CONFIG_CRYPTO_LZ4=m
arch/s390/configs/defconfig +0 -1
index 6c2f2bb4fbf8..eba7e76ccd6e 100644
@@ -766,11 +766,10 @@ CONFIG_CRYPTO_SEQIV=y
 CONFIG_CRYPTO_MD4=m
 CONFIG_CRYPTO_MD5=y
 CONFIG_CRYPTO_MICHAEL_MIC=m
 CONFIG_CRYPTO_RMD160=m
 CONFIG_CRYPTO_SM3_GENERIC=m
-CONFIG_CRYPTO_VMAC=m
 CONFIG_CRYPTO_WP512=m
 CONFIG_CRYPTO_XCBC=m
 CONFIG_CRYPTO_CRC32=m
 CONFIG_CRYPTO_842=m
 CONFIG_CRYPTO_LZ4=m
crypto/Kconfig +0 -10
index 6b0bfbccac08..2b2bb679e6b6 100644
@@ -1027,20 +1027,10 @@ config CRYPTO_STREEBOG
 
 	  References:
 	  https://tc26.ru/upload/iblock/fed/feddbb4d26b685903faa2ba11aea43f6.pdf
 	  https://tools.ietf.org/html/rfc6986
 
-config CRYPTO_VMAC
-	tristate "VMAC"
-	select CRYPTO_HASH
-	select CRYPTO_MANAGER
-	help
-	  VMAC is a message authentication algorithm designed for
-	  very high speed on 64-bit architectures.
-
-	  See https://fastcrypto.org/vmac for further information.
-
 config CRYPTO_WP512
 	tristate "Whirlpool"
 	select CRYPTO_HASH
 	help
 	  Whirlpool hash function (ISO/IEC 10118-3)
crypto/Makefile +0 -1
index 77abca715445..7c8a61c61b0f 100644
@@ -67,11 +67,10 @@ cryptomgr-y := algboss.o testmgr.o
 
 obj-$(CONFIG_CRYPTO_MANAGER2) += cryptomgr.o
 obj-$(CONFIG_CRYPTO_USER) += crypto_user.o
 obj-$(CONFIG_CRYPTO_CMAC) += cmac.o
 obj-$(CONFIG_CRYPTO_HMAC) += hmac.o
-obj-$(CONFIG_CRYPTO_VMAC) += vmac.o
 obj-$(CONFIG_CRYPTO_XCBC) += xcbc.o
 obj-$(CONFIG_CRYPTO_NULL2) += crypto_null.o
 obj-$(CONFIG_CRYPTO_MD4) += md4.o
 obj-$(CONFIG_CRYPTO_MD5) += md5.o
 obj-$(CONFIG_CRYPTO_RMD160) += rmd160.o
crypto/tcrypt.c +0 -4
index e9e7dceb606e..e1a74cb2cfbe 100644
@@ -1736,14 +1736,10 @@ static int do_test(const char *alg, u32 type, u32 mask, int m, u32 num_mb)
 
 	case 108:
 		ret = min(ret, tcrypt_test("hmac(rmd160)"));
 		break;
 
-	case 109:
-		ret = min(ret, tcrypt_test("vmac64(aes)"));
-		break;
-
 	case 111:
 		ret = min(ret, tcrypt_test("hmac(sha3-224)"));
 		break;
 
 	case 112:
crypto/testmgr.c +0 -6
index 1f5f48ab18c7..43eda27079de 100644
@@ -5747,16 +5747,10 @@ static const struct alg_test_desc alg_test_descs[] = {
 		.alg = "streebog512",
 		.test = alg_test_hash,
 		.suite = {
 			.hash = __VECS(streebog512_tv_template)
 		}
-	}, {
-		.alg = "vmac64(aes)",
-		.test = alg_test_hash,
-		.suite = {
-			.hash = __VECS(vmac64_aes_tv_template)
-		}
 	}, {
 		.alg = "wp256",
 		.test = alg_test_hash,
 		.suite = {
 			.hash = __VECS(wp256_tv_template)
crypto/testmgr.h +0 -153

163 lines not on this page · raw message

crypto/vmac.c deleted +0 -696

696 lines not on this page · raw message

base-commit: 7b6092ee7a4ce2d03dc65b87537889e8e1e0ab95

Signature · 1 line
2.47.1
Acked-by on v1 1/1
#1 lore raw
Quoted 41 lines · Eric Biggers

From: Eric Biggers <[email protected]>

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/[email protected]/).

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/[email protected]/). 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.

Quoted 8 lines

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 <[email protected]>
Cc Shane Wang <[email protected]>
Quoted 32 lines
---
 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

...

maintainer Acked-by on v1 1/1
#2 lore raw
In reply to Eric Biggers
Quoted 49 lines · Eric Biggers

From: Eric Biggers <[email protected]>

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/[email protected]/).

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/[email protected]/). 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 <[email protected]>
Cc Shane Wang <[email protected]>
Quoted 12 lines
 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 -

Gr{oetje,eeting}s,

Geert

Signature · 5 lines
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]

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
#3 lore raw
In reply to Eric Biggers
Quoted 5 lines · Eric Biggers

From: Eric Biggers <[email protected]>

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/[email protected]/).

...

Quoted 8 lines

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.

AFAIK it was never used for dm-integrity / cryptsetup and I am not even able to make it work for test now (isn't the vmac64 alg module init even broken?).

Just remove it...

Thanks,
Milan

maintainer
#4 lore raw
In reply to Eric Biggers
Quoted 78 lines · Eric Biggers

From: Eric Biggers <[email protected]>

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/[email protected]/).

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/[email protected]/). 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 <[email protected]>
Cc Shane Wang <[email protected]>

---

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(-)
Quoted 1 line

delete mode 100644 crypto/vmac.c

Patch applied. Thanks.

Signature · 3 lines
Email: Herbert Xu <[email protected]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt