Skip to contentSkip to conversation

ltp: fix af_alg02 to specify control data

PATCH In review Eric Biggers 2 participants 4 messages Aug 20, 2020 – Aug 21, 2020

Subsystems (2)
lore
Share & tools
lore
#0 lore raw

cover ltp: fix af_alg02 to specify control data

It isn't clearly defined what happens if you read from an AF_ALG request socket without previously sending the control data to begin an encryption or decryption operation. On some kernels the read will return 0, while on others it will block.

Testing this corner case isn't the purpose of af_alg02; it just wants to try to encrypt a zero-length message. So, change it to explicitly send a zero-length message with control data.

This fixes the test failure reported at
https://lkml.kernel.org/r/CA+G9fYtebf78TH-XpqArunHc1L6s9mHdLEbpY1EY9tSyDjp=sg@mail.gmail.com

Fixing the test in this way was also previously suggested at
https://lkml.kernel.org/r/[email protected]

Note, this patch doesn't change the fact that the read() still blocks on pre-4.14 kernels (which is a kernel bug), and thus the timeout logic in the test is still needed.

Eric Biggers (2):
lib/tst_af_alg: add tst_alg_sendmsg() crypto/af_alg02: send message with control data before reading

 include/tst_af_alg.h               | 32 +++++++++++++++
 lib/tst_af_alg.c                   | 64 ++++++++++++++++++++++++++++++
 testcases/kernel/crypto/af_alg02.c | 21 ++++++++--
 3 files changed, 114 insertions(+), 3 deletions(-)
Signature · 1 line
2.28.0
#1 lore raw

PATCH 1/2 lib/tst_af_alg: add tst_alg_sendmsg()

From: Eric Biggers <[email protected]>

Add a helper function which sends data to an AF_ALG request socket, including control data. This is needed by af_alg02, but it may also be useful for other AF_ALG tests in the future.

---
 include/tst_af_alg.h | 32 ++++++++++++++++++++++
 lib/tst_af_alg.c     | 64 ++++++++++++++++++++++++++++++++++++++++++++
 2 files changed, 96 insertions(+)
include/tst_af_alg.h +32 -0
index fc4b1989a..fd2ff0647 100644
@@ -133,4 +133,36 @@ int tst_alg_setup(const char *algtype, const char *algname,
 int tst_alg_setup_reqfd(const char *algtype, const char *algname,
 			const uint8_t *key, unsigned int keylen);
 
+/** Specification of control data to send to an AF_ALG request socket */
+struct tst_alg_sendmsg_params {
+
+	/** If true, send ALG_SET_OP with ALG_OP_ENCRYPT */
+	bool encrypt;
+
+	/** If true, send ALG_SET_OP with ALG_OP_DECRYPT */
+	bool decrypt;
+
+	/** If ivlen != 0, send ALG_SET_IV */
+	const uint8_t *iv;
+	unsigned int ivlen;
+
+	/** If assoclen != 0, send ALG_SET_AEAD_ASSOCLEN */
+	unsigned int assoclen;
+
+	/* Value to use as msghdr::msg_flags */
+	uint32_t msg_flags;
+};
+
+/**
+ * Send some data to an AF_ALG request socket, including control data.
+ * @param reqfd An AF_ALG request socket
+ * @param data The data to send
+ * @param datalen The length of data in bytes
+ * @param params Specification of the control data to send
+ *
+ * On failure, tst_brk() is called with TBROK.
+ */
+void tst_alg_sendmsg(int reqfd, const void *data, size_t datalen,
+		     const struct tst_alg_sendmsg_params *params);
+
 #endif /* TST_AF_ALG_H */
lib/tst_af_alg.c +64 -0

67 lines not on this page · raw message

Signature · 1 line
2.28.0
#2 lore raw

PATCH 2/2 crypto/af_alg02: send message with control data before reading

In reply to Eric Biggers

From: Eric Biggers <[email protected]>

It isn't clearly defined what happens if you read from an AF_ALG request socket without previously sending the control data to begin an encryption or decryption operation. On some kernels the read will return 0, while on others it will block.

Testing this corner case isn't the purpose of af_alg02; it just wants to try to encrypt a zero-length message. So, change it to explicitly send a zero-length message with control data.

This fixes the test failure reported at
https://lkml.kernel.org/r/CA+G9fYtebf78TH-XpqArunHc1L6s9mHdLEbpY1EY9tSyDjp=sg@mail.gmail.com

Fixing the test in this way was also previously suggested at
https://lkml.kernel.org/r/[email protected]

Note, this patch doesn't change the fact that the read() still blocks on pre-4.14 kernels (which is a kernel bug), and thus the timeout logic in the test is still needed.

---
 testcases/kernel/crypto/af_alg02.c | 21 ++++++++++++++++++---
 1 file changed, 18 insertions(+), 3 deletions(-)
testcases/kernel/crypto/af_alg02.c +18 -3
index fab0010c9..31d30777c 100644
@@ -21,14 +21,29 @@
 #include <pthread.h>
 #include <errno.h>
 
+#define SALSA20_IV_SIZE       8
+#define SALSA20_MIN_KEY_SIZE  16
+
 static void *verify_encrypt(void *arg)
 {
+	const uint8_t iv[SALSA20_IV_SIZE] = { 0 };
+	const struct tst_alg_sendmsg_params params = {
+		.encrypt = true,
+		.iv = iv,
+		.ivlen = SALSA20_IV_SIZE,
+	};
 	char buf[16];
-	int reqfd = tst_alg_setup_reqfd("skcipher", "salsa20", NULL, 16);
+	int reqfd = tst_alg_setup_reqfd("skcipher", "salsa20", NULL,
+					SALSA20_MIN_KEY_SIZE);
 
-	TST_CHECKPOINT_WAKE(0);
+	/* Send a zero-length message to encrypt */
+	tst_alg_sendmsg(reqfd, NULL, 0, &params);
 
-	/* With the bug the kernel crashed here */
+	/*
+	 * Read the zero-length encrypted data.
+	 * With the bug, the kernel crashed here.
+	 */
+	TST_CHECKPOINT_WAKE(0);
 	if (read(reqfd, buf, 16) == 0)
 		tst_res(TPASS, "Successfully \"encrypted\" an empty message");
 	else
Signature · 1 line
2.28.0
#3 lore raw
In reply to Eric Biggers

Hi Eric,

Quoted 12 lines

It isn't clearly defined what happens if you read from an AF_ALG request socket without previously sending the control data to begin an encryption or decryption operation. On some kernels the read will return 0, while on others it will block.

Testing this corner case isn't the purpose of af_alg02; it just wants to try to encrypt a zero-length message. So, change it to explicitly send a zero-length message with control data.

This fixes the test failure reported at
https://lkml.kernel.org/r/CA+G9fYtebf78TH-XpqArunHc1L6s9mHdLEbpY1EY9tSyDjp=sg@mail.gmail.com

Quoted 6 lines

Fixing the test in this way was also previously suggested at
https://lkml.kernel.org/r/[email protected]

Note, this patch doesn't change the fact that the read() still blocks on pre-4.14 kernels (which is a kernel bug), and thus the timeout logic in the test is still needed.

Thanks for the fix, merged!

Kind regards,
Petr