linux-kernel - Re: [PATCH tip] x86: vdso: Compute timens page offset statically

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] [day] [month] [year] [list]

Message-ID: <874j3nwo6o.ffs@tglx>
Date: Sun, 01 Dec 2024 14:03:11 +0100
From: Thomas Gleixner <tglx@...utronix.de>
To: "Jason A. Donenfeld" <Jason@...c4.com>
Cc: mingo@...hat.com, bp@...en8.de, dave.hansen@...ux.intel.com,
 x86@...nel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH tip] x86: vdso: Compute timens page offset statically

On Mon, Nov 18 2024 at 03:18, Jason A. Donenfeld wrote:
> On Tue, Sep 10, 2024 at 02:20:17PM +0200, Jason A. Donenfeld wrote:
>> On Tue, Sep 10, 2024 at 02:08:11PM +0200, Thomas Gleixner wrote:
>> > On Mon, Sep 09 2024 at 17:44, Jason A. Donenfeld wrote:
>> > > On Fri, Sep 06, 2024 at 09:06:55PM +0200, Jason A. Donenfeld wrote:
>> > >> The expression `((void *)&__timens_vdso_data - (void *)&__vdso_data)`
>> > >> seems harmless, but it actually results in quite a bit of code and two
>> > >> jumps, in a place that's supposed to be somewhat lean on code. The value
>> > >> of that calculation is always 3*PAGE_SIZE, as it turns out. Changing it
>> > >> to that results in a more modest cmov instruction being emitted. It also
>> > >> makes it a bit more clear what's happening.
>> > >> 
>> > >> To accomplish this, define offset macros in vvar.h, which can be shared
>> > >> by C code and by the linker script that decides where these pages will
>> > >> actually go.
>> > >
>> > > I noticed we've only got a week left til the merge window opens, so I
>> > > thought I should poke you about this, if you want to take this through
>> > > tip. I can also take it through my random.git tree with your ack, if
>> > > that's easier for you. (Assuming, of course, that this patch is actually
>> > > correct.) Let me know.
>> > 
>> > It's not the end of the world if this does not go in now. It's in my
>> > back log and that VDSO stuff needs more care than this particular thing
>> > as the recent discussion about vdso random on other architectures show.
>> 
>> Okay, that makes sense. And thanks for taking a look.
>
> Thought I'd poke again about this. It looks like this still applies to
> tip.

It's on my radar...