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

Message-ID: <76b5ba35f864764100c9a5a00d50d8fa4276cd98.camel@sipsolutions.net>
Date: Mon, 22 Sep 2025 14:12:52 +0200
From: Johannes Berg <johannes@...solutions.net>
To: Thomas Weißschuh <linux@...ssschuh.net>, Tiwei Bie
	 <tiwei.bie@...ux.dev>
Cc: 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 14:05 +0200, Thomas Weißschuh wrote:
> > The original issue could now be considered resolved. So in v3, we no
> > longer turn __vdso_getcpu into a syscall wrapper; we simply removed it.
> > Perhaps we could remove the whole VDSO before we implement the "real"
> > VDSO. However, its implementation is clean, so keeping it wouldn't hurt
> > and it could serve as a useful starting point for the "real" VDSO.
> 
> A "real" vDSO would require quite some more infrastructure.
> 

What's not "real" about the vDSO now? Yes it just implement syscalls
after the getcpu removal, but ... it's still a vDSO? I _have_ played
with getting data into it for the time-travel case, at least.

> And it is not even clear if such a vDSO will make a difference on UML.

Syscall overhead is _huge_ in UML, if it does anything but syscalls it
will _certainly_ make a difference.

> In my
> opinion if __vdso_getcpu() gets removed, the whole vDSO should go with
> it. The code can still be easily restored from git.

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.

> Also the functionality to map the host vDSO and vsyscall page into UML
> userspace looks very weird and error-prone. Maybe it can also go away.

Surely host vDSO etc. is never mapped into UML userspace and never is,
not sure what you're thinking of, but clearly that's wrong as written.

johannes