linux-kernel - Re: [PATCH] random: ensure mix_interrupt

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]

Date:   Fri, 11 Feb 2022 14:04:52 +0100
From:   "Jason A. Donenfeld" <Jason@...c4.com>
To:     Sebastian Andrzej Siewior <bigeasy@...utronix.de>
Cc:     LKML <linux-kernel@...r.kernel.org>,
        Linux Crypto Mailing List <linux-crypto@...r.kernel.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        "Theodore Ts'o" <tytso@....edu>,
        Dominik Brodowski <linux@...inikbrodowski.net>,
        Sultan Alsawaf <sultan@...neltoast.com>
Subject: Re: [PATCH] random: ensure mix_interrupt_randomness() is consistent

Sorry, missed this in your last email:

On Fri, Feb 11, 2022 at 9:16 AM Sebastian Andrzej Siewior
<bigeasy@...utronix.de> wrote:
> > +     do {
> > +             count_snapshot = (unsigned int)atomic_read(&fast_pool->count);
> > +             for (i = 0; i < ARRAY_SIZE(pool); ++i)
> > +                     pool[i] = READ_ONCE(fast_pool->pool_long[i]);
>
> Why do you avoid memcpy()? Since it is a small memcpy, I'm sure the
> compile will inline the register moves.

Because the compiler will otherwise reorder it to be after the two
counter reads. I checked. And a barrier() is too heavy as it flushes
the writes to the stack instead of keeping them read into registers.
READ_ONCE() is the exact semantics we care about here.

Jason