linux-kernel - Re: [PATCH v8 3/3] x86: vdso: Wire up getrandom() vDSO implementation

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: <cd01e0b4-579f-48fc-995f-6e1acebd02af@app.fastmail.com>
Date:   Mon, 28 Nov 2022 20:57:28 +0100
From:   "Arnd Bergmann" <arnd@...db.de>
To:     "Jason A . Donenfeld" <Jason@...c4.com>
Cc:     linux-kernel@...r.kernel.org, patches@...ts.linux.dev,
        "Thomas Gleixner" <tglx@...utronix.de>,
        linux-crypto@...r.kernel.org, linux-api@...r.kernel.org,
        x86@...nel.org, "Greg Kroah-Hartman" <gregkh@...uxfoundation.org>,
        "Adhemerval Zanella Netto" <adhemerval.zanella@...aro.org>,
        "Carlos O'Donell" <carlos@...hat.com>,
        "Florian Weimer" <fweimer@...hat.com>,
        "Christian Brauner" <brauner@...nel.org>,
        "Samuel Neves" <sneves@....uc.pt>
Subject: Re: [PATCH v8 3/3] x86: vdso: Wire up getrandom() vDSO implementation

On Mon, Nov 28, 2022, at 20:23, Jason A. Donenfeld wrote:
> On Mon, Nov 28, 2022 at 08:18:12PM +0100, Arnd Bergmann wrote:
>> On Mon, Nov 28, 2022, at 12:18, Jason A. Donenfeld wrote:
>
> That's more or less how v7 was, but Thomas thought the x86 stuff should
> be separate. So for v8, the organization is:
>
> 1) generic syscall
> 2) generic vdso
> 3) x86 wiring
>
> The primary advantage is that future archs wanting to add this now can
> just look at commit (3) only, and make a similar commit for that new
> arch.
>
> If you think a different organization outweighs that advantage, can you
> spell out what division of patches you want, and I'll do that for v9?
> Or maybe this v8 is okay?

My interest is that at the end of the series, all architectures
are hooked up with the same syscall number, which avoids confusion
and merge conflicts when we add the next syscall to all tables.

How about one patch to add all the syscall table entries, and then
have the x86 specific change just turn on the Kconfig symbol that
actually enables the syscall?

     Arnd