Received-SPF: pass (google.com: domain of linux-crypto-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Tue, 5 Jul 2022 15:18:48 +0200
From:   "Jason A. Donenfeld" <Jason@zx2c4.com>
To:     Holger Dengler <dengler@linux.ibm.com>
Cc:     Harald Freudenberger <freude@linux.ibm.com>,
        Heiko Carstens <hca@linux.ibm.com>,
        Vasily Gorbik <gor@linux.ibm.com>,
        Alexander Gordeev <agordeev@linux.ibm.com>,
        Christian Borntraeger <borntraeger@linux.ibm.com>,
        Juergen Christ <jchrist@linux.ibm.com>,
        linux-crypto@vger.kernel.org, linux-s390@vger.kernel.org
Subject: Re: [PATCH v1 1/1] s390/arch_random: Buffer true random data
Message-ID: <YsQ6OOrOWPhdynoM@zx2c4.com>
References: <20220705112712.4433-1-dengler@linux.ibm.com>
 <20220705112712.4433-2-dengler@linux.ibm.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <20220705112712.4433-2-dengler@linux.ibm.com>
Precedence: bulk

Hi Holger,

On Tue, Jul 05, 2022 at 01:27:12PM +0200, Holger Dengler wrote:
> The trng instruction is very expensive and has a constant runtime for
> getting 0 to 32 bytes of (conditioned) true random data. Calling trng for
> in arch_get_random_seed_long() for each 8 bytes is too time-consuming,
> especially if it is called in interrupt context.
> 
> This implementation buffers the trng data and deliver parts of it to the

This patch seems to be repeating the same mistake I just cleaned up.
Specifically, an advantage of a CPU RNG is that it can always provide
*fresh* entropy, so that if, say, the system state is dumped, the CPU
will continue to provide fresh new uncompromised values. When you buffer
those values, they cease to be fresh.

But more realistically, have you benchmarked this and seen that it's
actually required? These functions are called once at boot, and then
when the RNG is reseeded, which happens around once a minute. That's
pretty darn rare. When you consider all the cycles that are completed
over the course of a minute, whatever the cost of the TRNG is seems
pretty negligible.

So anyway, maybe it'd be best to look at the "big picture" problem you
want to solve, rather than what looks to me like an attempt to solve a
problem that doesn't exist. Or maybe it does? If so, I'd be interested
to know when and how and where and such.

Jason