All of lore.kernel.org
 help / color / mirror / Atom feed
From: Petr Vorel <pvorel@suse.cz>
To: Eric Biggers <ebiggers@kernel.org>
Cc: ltp@lists.linux.it
Subject: Re: [LTP] [PATCH v2 1/1] tst_af_alg: Another fix for disabled weak cipher
Date: Wed, 22 Dec 2021 18:01:37 +0100	[thread overview]
Message-ID: <YcNZ8TDUR8+V+t6g@pevik> (raw)
In-Reply-To: <YcNE2Yt4zLs4ayz7@quark>

Hi Eric,

> 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?
It reports ELIBBAD. Am I missing something?

> > @@ -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.
Sure, but split into 2 functions (add tst_try_alg() and use it in
tst_have_alg()) suggested by Cyril should solve it.

> > @@ -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?
I'm sorry The addition is left over from testing, it should have not been here.

Kind regards,
Petr

> - Eric

-- 
Mailing list info: https://lists.linux.it/listinfo/ltp

  reply	other threads:[~2021-12-22 17:01 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-12-20 21:27 [LTP] [PATCH v2 1/1] tst_af_alg: Another fix for disabled weak cipher Petr Vorel
2021-12-21 11:11 ` Cyril Hrubis
2021-12-21 12:03   ` Petr Vorel
2021-12-22 14:45     ` Petr Vorel
2021-12-22 16:01       ` Cyril Hrubis
2021-12-22 16:49         ` Petr Vorel
2021-12-22 15:31 ` Eric Biggers
2021-12-22 17:01   ` Petr Vorel [this message]
2021-12-22 17:58     ` Eric Biggers
2021-12-22 19:01       ` Petr Vorel
2022-01-04 11:54 ` Petr Vorel
2022-01-11  5:29   ` Herbert Xu
2022-01-11  6:44     ` Petr Vorel

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=YcNZ8TDUR8+V+t6g@pevik \
    --to=pvorel@suse.cz \
    --cc=ebiggers@kernel.org \
    --cc=ltp@lists.linux.it \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.