Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
MIME-Version: 1.0
References: <CAHmME9qTA90=GEr6h1GZh0CjS+6tpe5uuqkYoJVv79h0zd0w1w@mail.gmail.com>
 <20220719130207.147536-1-Jason@zx2c4.com>
In-Reply-To: <20220719130207.147536-1-Jason@zx2c4.com>
From:   "Jason A. Donenfeld" <Jason@zx2c4.com>
Date:   Mon, 25 Jul 2022 00:47:50 +0200
Message-ID: <CAHmME9o7cNRPxy+WuM6-13ak9RNo1UH8-4qMArSACLs8LYAt8g@mail.gmail.com>
Subject: Re: [PATCH v3] random: handle archrandom with multiple longs
To:     Borislav Petkov <bp@suse.de>
Cc:     LKML <linux-kernel@vger.kernel.org>, X86 ML <x86@kernel.org>
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

Hey Borislav (or other x86ers),

On Tue, Jul 19, 2022 at 3:02 PM Jason A. Donenfeld <Jason@zx2c4.com> wrote:
>
> The archrandom interface was originally designed for x86, which supplies
> RDRAND/RDSEED for receiving random words into registers, resulting in
> one function to generate an int and another to generate a long. However,
> other architectures don't follow this.
>
> On arm64, the SMCCC TRNG interface can return between 1 and 3 longs. On
> s390, the CPACF TRNG interface can return arbitrary amounts, with 32
> longs having the same cost as one. On UML, the os_getrandom() interface
> can return arbitrary amounts.
>
> So change the api signature to take a "max_longs" parameter designating
> the maximum number of longs requested, and then return the number of
> longs generated.
>
> Since callers need to check this return value and loop anyway, each arch
> implementation does not bother implementing its own loop to try again to
> fill the maximum number of longs. Additionally, all existing callers
> pass in a constant max_longs parameter. Taken together, these two things
> mean that the codegen doesn't really change much for one-word-at-a-time
> platforms, while performance is greatly improved on platforms such as
> s390.

This patch now has acks from Heiko, Catalin, Mark, and Michael,
covering the arm, ppc, and s390 changes. The changes to s390 and arm
were non-trivial so those acks were quite meaningful. On x86 and ppc,
the code compiles down to basically the same assembly and the change
really doesn't matter at all. Nonetheless, I thought I should give you
a final poke in case you want to ack or nack this, lest I step on the
tip.git of your shoes.

Jason