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;
From:   Thomas Gleixner <tglx@linutronix.de>
To:     "Jason A. Donenfeld" <Jason@zx2c4.com>,
        Arnd Bergmann <arnd@arndb.de>
Cc:     Florian Weimer <fweimer@redhat.com>, linux-kernel@vger.kernel.org,
        patches@lists.linux.dev, 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>,
        Christian Brauner <brauner@kernel.org>
Subject: Re: [PATCH v10 3/4] random: introduce generic vDSO getrandom()
 implementation
In-Reply-To: <CAHmME9oGffi539nEAJkOjC-2yAR+0Ra+wQw5oG6Y6+CRr5e62g@mail.gmail.com>
References: <20221129210639.42233-1-Jason@zx2c4.com>
 <20221129210639.42233-4-Jason@zx2c4.com>
 <878rjs7mcx.fsf@oldenburg.str.redhat.com> <Y4dt1dLZMmogRlKa@zx2c4.com>
 <Y4dvz4d0dpFzJZ9L@zx2c4.com>
 <16ec2a7a-c469-4732-aeca-e74a9fb88d3e@app.fastmail.com>
 <CAHmME9rpdCGLQzfsNkX=mLHfWeEWi4TyrOf_2rP_9hsyX9v6ow@mail.gmail.com>
 <574ad32d-566e-4c18-a645-1470fc081ede@app.fastmail.com>
 <CAHmME9oGffi539nEAJkOjC-2yAR+0Ra+wQw5oG6Y6+CRr5e62g@mail.gmail.com>
Date:   Wed, 30 Nov 2022 18:00:07 +0100
Message-ID: <8735a0tm20.ffs@tglx>
MIME-Version: 1.0
Content-Type: text/plain
Precedence: bulk

On Wed, Nov 30 2022 at 16:47, Jason A. Donenfeld wrote:
> On Wed, Nov 30, 2022 at 4:29 PM Arnd Bergmann <arnd@arndb.de> wrote:
>> I see what you mean now. However this means your vdso32 copies
>> are different between 32-bit and 64-bit kernels. If you need to
>> access one of the fields from assembler, it even ends up
>> different at source level, which adds a bit of complexity.
>>
>> Making the interface configuration-independent makes it obvious
>> to the reader that none of these problems can happen.
>
> Except ideally, these are word-sized accesses (where only compat code
> has to suffer I suppose).

While I hate it with a passion, there is actually a valid reason to use
this ugly typedef.

On 32bit architectures which have load/store tearing of 64bit variables
into two 32bit accesses due to ISA limitations, that results in
undefined behaviour when write and read are concurrent. Neither
READ_ONCE() nor WRITE_ONCE help there.

Though that begs the question whether we need a 64bit generation counter
for the VDSO at all.

Thanks,

        tglx