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-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Yt5hwxC1xgvA8Asw@zx2c4.com>
Date:   Mon, 25 Jul 2022 11:26:27 +0200
From:   "Jason A. Donenfeld" <Jason@...c4.com>
To:     Borislav Petkov <bp@...e.de>
Cc:     linux-kernel@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
        linuxppc-dev@...ts.ozlabs.org, linux-s390@...r.kernel.org,
        x86@...nel.org, Will Deacon <will@...nel.org>,
        Alexander Gordeev <agordeev@...ux.ibm.com>,
        Thomas Gleixner <tglx@...utronix.de>,
        "H . Peter Anvin" <hpa@...or.com>,
        Catalin Marinas <catalin.marinas@....com>,
        Heiko Carstens <hca@...ux.ibm.com>,
        Johannes Berg <johannes@...solutions.net>,
        Mark Rutland <mark.rutland@....com>,
        Harald Freudenberger <freude@...ux.ibm.com>,
        Michael Ellerman <mpe@...erman.id.au>
Subject: Re: [PATCH v3] random: handle archrandom with multiple longs

Hi Boris,

On Mon, Jul 25, 2022 at 11:19:01AM +0200, Borislav Petkov wrote:
> On Tue, Jul 19, 2022 at 03:02:07PM +0200, Jason A. Donenfeld wrote:
> > 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.
> 
> Hmm, maybe this has come up already but it reads weird.
> 
> If I have a function arch_get_random_longs(), I'd expect it to give me
> the number of longs I requested or say, error.
> 
> Why do the callers need to loop?
> 
> If I have to loop, I'd call the "get me one long" function and loop N
> times.

Answered partially in the commit message you quoted and partially here:
https://lore.kernel.org/lkml/YtqIbrds53EuyqPE@zx2c4.com/

Note that arch_get_random_longs() is not a general purpose function. For
that there used to be get_random_bytes_arch(), but that no longer exists
as people shouldn't be using this stuff directly. arch_get_random_longs()
is a special purpose function mainly intended for use by the RNG itself.

More directly, the reason we don't want to error is because the use case
has fallbacks meant to handle errors. The cascade looks like this
(quoting from the other email):

    unsigned long array[whatever];
    for (i = 0; i < ARRAY_SIZE(array);) {
        longs = arch_get_random_seed_longs(&array[i], ARRAY_SIZE(array) - i);
        if (longs) {
            i += longs;
            continue;
        }
        longs = arch_get_random_longs(&array[i], ARRAY_SIZE(array) - i);
        if (longs) {
            i += longs;
            continue;
        }
        array[i++] = random_get_entropy();
    }

It tries to get the best that it can as much as it can, but isn't going
to block or do anything too nuts for that.

Anyway, from an x86 perspective, I can't imagine you object to this
change, right? Codegen is the same.

Jason

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ