linux-kernel - Re: [PATCH v2 03/10] um: vdso: Implement __vdso

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: <96ae8e726480a36a37d472106b761a141394e845.camel@sipsolutions.net>
Date: Mon, 22 Sep 2025 19:07:27 +0200
From: Johannes Berg <johannes@...solutions.net>
To: Thomas Weißschuh <linux@...ssschuh.net>
Cc: Tiwei Bie <tiwei.bie@...ux.dev>, richard@....at, 
	anton.ivanov@...bridgegreys.com, benjamin@...solutions.net, arnd@...db.de, 
	linux-um@...ts.infradead.org, linux-kernel@...r.kernel.org, 
	tiwei.btw@...group.com
Subject: Re: [PATCH v2 03/10] um: vdso: Implement __vdso_getcpu() via syscall

On Mon, 2025-09-22 at 18:04 +0200, Thomas Weißschuh wrote:

> > I don't know if I'd say "just overhead" - depends on which path is more
> > optimised in a typical libc implementation? I'd basically think it's
> > identical, no? You either link to the vDSO, or a __weak same function in
> > the libc?
> 
> The code also needs to be built and maintained.

Yeah, fair, though the vDSO doesn't really do anything, and if we do
want to use it then having a working version beats having to re-do it
from scratch, which 

>  AFAIK __weak is only for
> the compile-time linker. The vDSO call will be an indirect call.

yeah, I looked at the links you'd sent earlier only later ...

> > > > I mean ... on the one hand, sure, it doesn't really do much after this,
> > > > but OTOH it lets userspace actually use that path? So might be useful.
> > > 
> > > What advantage does userspace have from it?
> > 
> > Right now, none? But it's easier to play with if you have the
> > infrastructure, and I'm not convinced there's a _disadvantage_?
> 
> So far that hasn't happened. The disadvantages are the ones from above,
> nothing critical. But of course it is your subsystem and your call to make.

Yeah, kind of agree, though I'd like to actually use it - especially in
time-travel mode - but haven't really gotten time to add it. Having it
maintained in-tree is a bit nicer in case of global updates, but yeah,
ultimately it's not really all that important either way.

I guess we could get getrandom() pretty easily by taking the x86 one.

I actually have half a patch somewhere that rejiggers the UM vDSO to be
more like normal architectures, using lib/vdso/gettimeofday.c and making
the build more regular etc. Maybe I should dig that up and try to make
it work entirely - it was part of a previous attempt of adding the time-
travel thing I mentioned.

> > Huh, hm, yeah I forgot about that ... 32-bit. Yeah, agree we should just
> > kill that. I'm not even sure it works with the host kernel trapping
> > there? Oh well.
> 
> Ack, do you want me to send a patch? This was my real gripe with the UM
> vDSO. I want to enable time namespaces for all architectures but these
> need to be handled in the vDSO properly. For the 64-bit stub vDSO it's
> not a problem as the syscalls will work correctly.
> But the interaction with the weird 32-bit logic on the other hand...

I guess? But I'm confused by what you say about it being related to time
namespaces, the vsyscall stuff doesn't really _do_ anything, assuming it
works at all? It's not like the host actually could be doing anything
other than syscalls there, which are intercepted? If it were doing
anything else, it wouldn't work in UML in the first place?

johannes