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: <ZuA5gaOhJNwDSb4x@zx2c4.com>
Date: Tue, 10 Sep 2024 14:20:17 +0200
From: "Jason A. Donenfeld" <Jason@...c4.com>
To: Thomas Gleixner <tglx@...utronix.de>
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 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.

Jason

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ