[LTP] [PATCH v2 1/1] tst_af_alg: Another fix for disabled weak cipher

[Eric Biggers]

On Mon, Dec 20, 2021 at 10:27:56PM +0100, Petr Vorel wrote:
> tst_af_alg.c:84: TBROK: unexpected error binding AF_ALG socket to hash algorithm 'md5': ELIBBAD (80)

This seems like a kernel bug; shouldn't the kernel report ENOENT for the
algorithms that fips_enabled isn't allowing, just like other algorithms that
aren't available?  Have you checked with linux-crypto@vger.kernel.org that the
current behavior is actually intentional?

> @@ -77,11 +86,16 @@ bool tst_have_alg(const char *algtype, const char *algname)
>  
>  	ret = bind(algfd, (const struct sockaddr *)&addr, sizeof(addr));
>  	if (ret != 0) {
> -		if (errno != ENOENT) {
> +		if (errno == ELIBBAD && tst_fips_enabled()) {
> +			tst_res(TCONF,
> +				"FIPS enabled => %s algorithm '%s' disabled",
> +				algtype, algname);
> +		} else if (errno != ENOENT) {
>  			tst_brk(TBROK | TERRNO,
>  				"unexpected error binding AF_ALG socket to %s algorithm '%s'",
>  				algtype, algname);
>  		}
> +
>  		have_alg = false;
>  	}

This function is supposed to return false if the algorithm isn't available; it
shouldn't be skipping the test.

> @@ -22,8 +23,9 @@ static void test_with_hash_alg(const char *hash_algname)
>  	char key[4096] = { 0 };
>  
>  	if (!tst_have_alg("hash", hash_algname)) {
> -		tst_res(TCONF, "kernel doesn't have hash algorithm '%s'",
> -			hash_algname);
> +		if (errno != ELIBBAD)
> +			tst_res(TCONF, "kernel doesn't have hash algorithm '%s'",
> +				hash_algname);
>  		return;
>  	}
>  	sprintf(hmac_algname, "hmac(%s)", hash_algname);

Why treat this case any differently from any other hash algorithm that isn't
available?

- Eric