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;
Feedback-ID: i56a14606:Fastmail
User-Agent: Cyrus-JMAP/3.7.0-alpha0-1115-g8b801eadce-fm-20221102.001-g8b801ead
Mime-Version: 1.0
Message-Id: <974d7fcb-efbb-4508-a4cb-4b5328669c14@app.fastmail.com>
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 17:13:18 +0100
From:   "Arnd Bergmann" <arnd@arndb.de>
To:     "Jason A . Donenfeld" <Jason@zx2c4.com>
Cc:     "Florian Weimer" <fweimer@redhat.com>,
        linux-kernel@vger.kernel.org, patches@lists.linux.dev,
        "Thomas Gleixner" <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>,
        "Christian Brauner" <brauner@kernel.org>
Subject: Re: [PATCH v10 3/4] random: introduce generic vDSO getrandom() implementation
Content-Type: text/plain
Precedence: bulk

On Wed, Nov 30, 2022, at 16:47, Jason A. Donenfeld wrote:

>> > There's padding at the end of the structure, yes. But both
>> > `generation` and `is_ready` will be at the same offset. If the
>> > structure grows, then sure, that'll have to be taken into account. But
>> > that's not a problem because this is a private implementation detail
>> > between the vdso code and the kernel.
>>
>> I was not concerned about incompatibility here, but rather about
>> possibly leaking kernel data to the vdso page.
>
> The vvar page starts out zeroed, no?

The typical problem is someone doing a copy_to_user() of an in-kernel
structure into the userspace side, which would then copy the
padding as well. If the source is on the stack, a malicious caller
can trick the another syscall into leaving sensitive data at this
exact stack location. Again, I'm not saying that your code is
vulnerable to that type of attack, just that making all ABI
structures not have holes is useful for auditing.

    Arnd