From: Florian Weimer <fweimer@redhat.com>
To: "Jason A. Donenfeld" <Jason@zx2c4.com>
Cc: linux-kernel@vger.kernel.org, patches@lists.linux.dev,
tglx@linutronix.de, linux-crypto@vger.kernel.org,
linux-api@vger.kernel.org, x86@kernel.org,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Adhemerval Zanella Netto <adhemerval.zanella@linaro.org>,
Carlos O'Donell <carlos@redhat.com>,
Arnd Bergmann <arnd@arndb.de>,
Christian Brauner <brauner@kernel.org>
Subject: Re: [PATCH v11 3/4] random: introduce generic vDSO getrandom() implementation
Date: Mon, 05 Dec 2022 20:35:09 +0100 [thread overview]
Message-ID: <87wn75prte.fsf@oldenburg.str.redhat.com> (raw)
In-Reply-To: <Y45Ar3mwRBSr+X7F@zx2c4.com> (Jason A. Donenfeld's message of "Mon, 5 Dec 2022 20:04:15 +0100")
* Jason A. Donenfeld:
> Hi Florian,
>
> On Mon, Dec 05, 2022 at 07:56:47PM +0100, Florian Weimer wrote:
>> * Jason A. Donenfeld:
>>
>> > +retry_generation:
>> > + /*
>> > + * @rng_info->generation must always be read here, as it serializes @state->key with the
>> > + * kernel's RNG reseeding schedule.
>> > + */
>> > + current_generation = READ_ONCE(rng_info->generation);
>>
>> > + if (unlikely(READ_ONCE(state->generation) != READ_ONCE(rng_info-
>>
>> I'm pretty sure you need some sort of barrier here. We have a similar
>> TM-lite construct in glibc ld.so for locating link maps by address, and
>> there the compiler performed reordering.
>>
>> _dl_find_object miscompilation on powerpc64le
>> <https://sourceware.org/bugzilla/show_bug.cgi?id=28745>
>>
>> I'm not familiar with READ_ONCE, but Documentation/atomic_t.txt suggests
>> it's a “regular LOAD”, and include/asm-generic/rwonce.h concurs.
>
> Do you mean compiler barriers or SMP barriers?
Compiler barrier.
>> Likewise, the signal safety mechanism needs compiler barriers (signal
>> fences).
>
> READ_ONCE() should prevent the compiler from reordering the read.
READ_ONCE looks just like a volatile read. Other reads can be ordered
around it.
For example, this:
void f1 (int, int, int);
extern int a;
extern int b;
void
f2 (volatile int *p)
{
int a1 = a;
int p1 = *p;
int b1 = b;
return f1 (a1, p1, b1);
}
Turns into:
.globl f2
.type f2, @function
f2:
movl (%rdi), %esi
movl b(%rip), %edx
movl a(%rip), %edi
jmp f1
Looks like compiler reodering to me.
>> I'm also not sure how READ_ONCE realizes atomic 64-bit reads on 32-bit
>> platforms. i386 can do them in user space via the FPU worst-case (if
>> the control word hasn't been corrupted). CMPXCHG8B is not applicable
>> here because it's a read-only mapping. Maybe add a comment at least
>> about that “strong prevailing wind”?
>
> There's read tearing in that case, which isn't super, but perhaps not
> all together harmful.
Maybe add a comment that it was considered?
Thanks,
Florian
next prev parent reply other threads:[~2022-12-05 19:39 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-12-05 2:00 [PATCH v11 0/4] implement getrandom() in vDSO Jason A. Donenfeld
2022-12-05 2:00 ` [PATCH v11 1/4] random: add vgetrandom_alloc() syscall Jason A. Donenfeld
2022-12-05 18:34 ` Florian Weimer
2022-12-05 18:38 ` Jason A. Donenfeld
2022-12-05 19:13 ` Jann Horn
2022-12-05 20:02 ` Jason A. Donenfeld
2022-12-05 20:06 ` Florian Weimer
2022-12-06 12:57 ` Jason A. Donenfeld
2022-12-05 2:00 ` [PATCH v11 2/4] arch: allocate vgetrandom_alloc() syscall number Jason A. Donenfeld
2022-12-05 2:00 ` [PATCH v11 3/4] random: introduce generic vDSO getrandom() implementation Jason A. Donenfeld
2022-12-05 18:56 ` Florian Weimer
2022-12-05 19:04 ` Jason A. Donenfeld
2022-12-05 19:35 ` Florian Weimer [this message]
2022-12-05 2:00 ` [PATCH v11 4/4] x86: vdso: Wire up getrandom() vDSO implementation Jason A. Donenfeld
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=87wn75prte.fsf@oldenburg.str.redhat.com \
--to=fweimer@redhat.com \
--cc=Jason@zx2c4.com \
--cc=adhemerval.zanella@linaro.org \
--cc=arnd@arndb.de \
--cc=brauner@kernel.org \
--cc=carlos@redhat.com \
--cc=gregkh@linuxfoundation.org \
--cc=linux-api@vger.kernel.org \
--cc=linux-crypto@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=patches@lists.linux.dev \
--cc=tglx@linutronix.de \
--cc=x86@kernel.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).