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: <bfa3b5fe-ae5d-4647-a49e-b2b53a46de4f@t-8ch.de>
Date: Thu, 25 Sep 2025 19:08:31 +0200
From: Thomas Weißschuh <linux@...ssschuh.net>
To: Johannes Berg <johannes@...solutions.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 2025-09-22 19:07:27+0200, Johannes Berg wrote:
> On Mon, 2025-09-22 at 18:04 +0200, Thomas Weißschuh wrote:

(...)

> > > > > 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.

Yeah, the only architecture-specific part there is the assembly chacha
implementation. And that will be the same one as used by regular x86.

> 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.

Sounds good. And let me know if you want me to look at it.
Using the generic vDSO library and datastore is mandatory nowadays for
"real" vDSOs.

> > > 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?

In emulation mode the trapping kernel will not actually trigger a
syscall but calculate the time in kernel space and write the results to
the respective registers. If I understand correctly the trap is handled
by the host kernel, so that would bypass UML completely.
My wording was a bit wonky. I stumbled upon this while looking for
potential time namespace compatibility issues. And with time namespaces
the chance for a clock mismatch between UML and the host are higher.


Thomas