linux-kernel - [Question] Redundant ternary operators in nhpoly1305/sha256 digest functions?

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-Id: <20260114153839.3649359-1-ingyujang25@korea.ac.kr>
Date: Thu, 15 Jan 2026 00:38:39 +0900
From: Jang Ingyu <ingyujang25@...ea.ac.kr>
To: Herbert Xu <herbert@...dor.apana.org.au>,
	"David S . Miller" <davem@...emloft.net>
Cc: Thomas Gleixner <tglx@...utronix.de>,
	Ingo Molnar <mingo@...hat.com>,
	Borislav Petkov <bp@...en8.de>,
	Dave Hansen <dave.hansen@...ux.intel.com>,
	x86@...nel.org,
	"H . Peter Anvin" <hpa@...or.com>,
	linux-crypto@...r.kernel.org,
	linux-kernel@...r.kernel.org,
	Ingyu Jang <ingyujang25@...ea.ac.kr>
Subject: [Question] Redundant ternary operators in nhpoly1305/sha256 digest functions?

From: Ingyu Jang <ingyujang25@...ea.ac.kr>

Hi,

I noticed that in arch/x86/crypto/, several digest functions use
the ternary operator (?:) to chain function calls:

In nhpoly1305-avx2-glue.c and nhpoly1305-sse2-glue.c:

  return crypto_nhpoly1305_init(desc) ?:
         nhpoly1305_xxx_update(desc, src, srclen) ?:
         crypto_nhpoly1305_final(desc, out);

In sha256_ssse3_glue.c (sha256_ssse3_digest, sha256_avx_digest,
sha256_avx2_digest, sha256_ni_digest):

  return sha256_base_init(desc) ?:
         sha256_xxx_finup(desc, data, len, out);

However, all the functions being checked always return 0:
  - crypto_nhpoly1305_init() always returns 0
  - nhpoly1305_xxx_update() always returns 0
  - crypto_nhpoly1305_final() always returns 0
  - sha256_base_init() always returns 0

This makes the short-circuit evaluation of ?: unnecessary.

Is this intentional defensive coding for potential future changes,
or could this be cleaned up?

Thanks,
Ingyu Jang