All of lore.kernel.org
 help / color / mirror / Atom feed
From: Stephan Mueller <smueller@chronox.de>
To: Edward Adam Davis <eadavis@qq.com>
Cc: herbert@gondor.apana.org.au, davem@davemloft.net, eadavis@qq.com,
	linux-crypto@vger.kernel.org, linux-kernel@vger.kernel.org,
	syzbot+e8bcd7ee3db6cb5cb875@syzkaller.appspotmail.com,
	syzkaller-bugs@googlegroups.com
Subject: Re: [PATCH V2] crypto: Mark intermediary memory as clean
Date: Mon, 18 Aug 2025 15:13:47 +0200	[thread overview]
Message-ID: <7740195.jRhZ6ZUK3Y@tauon> (raw)
In-Reply-To: <tencent_F8BAB8BB23338A9E2C1B4F4BD11BD9252E08@qq.com>

Am Montag, 18. August 2025, 14:43:36 Mitteleuropäische Sommerzeit schrieb 
Edward Adam Davis:

Hi Edward,

> On Mon, 18 Aug 2025 20:30:29 +0800, Herbert Xu wrote:
> > Their values are equal, so why use sizeof to calculate?
> > Similarly, "if (sizeof(intermediary) !=
> > crypto_shash_digestsize(desc->tfm)) {", why not just use
> > SHA3_256_DIGEST_SIZE?
> 
> Hi Stephan Mueller, can you explain it?

If the question is why using sizeof(intermediary) instead of 
SHA3_256_DIGEST_SIZE, then it is very trivial: I always want to avoid any kind 
of double work. If for any reason the buffer size of intermediary changes, the 
current code only requires *one* location to fix it.

When changing the branching condition to use SHA3_256_DIGEST_SIZE, we would 
have to change *two* locations which is more error-prone than to change one. 
This approach is my common coding style to try to minimize the possibilities 
where inconsistencies can occur.

Ciao
Stephan



  reply	other threads:[~2025-08-18 13:19 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-08-08  8:07 [syzbot] [crypto?] KMSAN: kernel-infoleak in rng_recvmsg syzbot
2025-08-09  7:19 ` Edward Adam Davis
2025-08-09  9:52   ` syzbot
2025-08-09  9:59 ` [PATCH] crypto: Prevent " Edward Adam Davis
2025-08-16  9:17   ` Herbert Xu
2025-08-17  8:51     ` Herbert Xu
2025-08-17 10:59       ` [PATCH V2] crypto: Mark intermediary memory as clean Edward Adam Davis
2025-08-17 11:40         ` Herbert Xu
2025-08-18 12:17           ` Edward Adam Davis
2025-08-18 12:30             ` Herbert Xu
2025-08-18 12:43               ` Edward Adam Davis
2025-08-18 13:13                 ` Stephan Mueller [this message]
2025-08-18 13:24                   ` [PATCH V3] " Edward Adam Davis
2025-08-18 13:32                     ` Stephan Mueller
2025-08-30  8:45                     ` Herbert Xu
2025-08-26 13:51     ` [PATCH] crypto: Prevent kernel-infoleak in rng_recvmsg Ard Biesheuvel
2025-08-26 16:58       ` Kees Cook

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=7740195.jRhZ6ZUK3Y@tauon \
    --to=smueller@chronox.de \
    --cc=davem@davemloft.net \
    --cc=eadavis@qq.com \
    --cc=herbert@gondor.apana.org.au \
    --cc=linux-crypto@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=syzbot+e8bcd7ee3db6cb5cb875@syzkaller.appspotmail.com \
    --cc=syzkaller-bugs@googlegroups.com \
    /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.