linux-kernel - Re: [PATCH v3 00/18] vDSO: Introduce generic data storage

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: <ff83dc5c91b4e46bcf2d99680ec6af250fb05b27.camel@infradead.org>
Date: Thu, 06 Feb 2025 09:31:42 +0000
From: David Woodhouse <dwmw2@...radead.org>
To: Thomas Weißschuh <thomas.weissschuh@...utronix.de>, 
 "James E.J. Bottomley" <James.Bottomley@...senPartnership.com>, Helge
 Deller <deller@....de>, Andy Lutomirski <luto@...nel.org>,  Thomas Gleixner
 <tglx@...utronix.de>, Vincenzo Frascino <vincenzo.frascino@....com>,
 Anna-Maria Behnsen <anna-maria@...utronix.de>, Frederic Weisbecker
 <frederic@...nel.org>,  Andrew Morton <akpm@...ux-foundation.org>, Catalin
 Marinas <catalin.marinas@....com>, Will Deacon <will@...nel.org>, Theodore
 Ts'o <tytso@....edu>, "Jason A. Donenfeld" <Jason@...c4.com>, Paul Walmsley
 <paul.walmsley@...ive.com>, Palmer Dabbelt <palmer@...belt.com>, Albert Ou
 <aou@...s.berkeley.edu>, Huacai Chen <chenhuacai@...nel.org>, WANG Xuerui
 <kernel@...0n.name>, Russell King <linux@...linux.org.uk>, Heiko Carstens
 <hca@...ux.ibm.com>, Vasily Gorbik <gor@...ux.ibm.com>, Alexander Gordeev
 <agordeev@...ux.ibm.com>, Christian Borntraeger
 <borntraeger@...ux.ibm.com>, Sven Schnelle <svens@...ux.ibm.com>, Thomas
 Bogendoerfer <tsbogend@...ha.franken.de>, Michael Ellerman
 <mpe@...erman.id.au>, Nicholas Piggin <npiggin@...il.com>, Christophe Leroy
 <christophe.leroy@...roup.eu>, Naveen N Rao <naveen@...nel.org>, Madhavan
 Srinivasan <maddy@...ux.ibm.com>, Ingo Molnar <mingo@...hat.com>, Borislav
 Petkov <bp@...en8.de>, Dave Hansen <dave.hansen@...ux.intel.com>,
 x86@...nel.org, "H. Peter Anvin" <hpa@...or.com>,  Arnd Bergmann
 <arnd@...db.de>, Guo Ren <guoren@...nel.org>
Cc: linux-parisc@...r.kernel.org, linux-kernel@...r.kernel.org, 
 linux-arm-kernel@...ts.infradead.org, linux-riscv@...ts.infradead.org, 
 loongarch@...ts.linux.dev, linux-s390@...r.kernel.org, 
 linux-mips@...r.kernel.org, linuxppc-dev@...ts.ozlabs.org, 
 linux-arch@...r.kernel.org, Nam Cao <namcao@...utronix.de>, 
 linux-csky@...r.kernel.org, "Ridoux, Julien" <ridouxj@...zon.com>, "Luu,
 Ryan" <rluu@...zon.com>, kvm <kvm@...r.kernel.org>
Subject: Re: [PATCH v3 00/18] vDSO: Introduce generic data storage

On Tue, 2025-02-04 at 13:05 +0100, Thomas Weißschuh wrote:
> Currently each architecture defines the setup of the vDSO data page on
> its own, mostly through copy-and-paste from some other architecture.
> Extend the existing generic vDSO implementation to also provide generic
> data storage.
> This removes duplicated code and paves the way for further changes to
> the generic vDSO implementation without having to go through a lot of
> per-architecture changes.
> 
> Based on v6.14-rc1 and intended to be merged through the tip tree.

Thanks for working on this. Is there a plan to expose the time data
directly to userspace in a form which is usable *other* than by
function calls which get the value of the clock at a given moment?

For populating the vmclock device¹ we need to know the actual
relationship between the hardware counter (TSC, arch timer, etc.) and
real time in order to propagate that to the guest.

I see two options for doing this:

 1. Via userspace, exposing the vdso time data (and a notification when
    it changes?) and letting the userspace VMM populate the vmclock.
    This is complex for x86 because of TSC scaling; in fact userspace
    doesn't currently know the precise scaling from host to guest TSC
    so we'd have to be able to extract that from KVM.

 2. In kernel, asking KVM to populate the vmclock structure much like
    it does other pvclocks shared with the guest. KVM/x86 already uses
    pvclock_gtod_register_notifier() to hook changes; should we expand
    on that? The problem with that notifier is that it seems to be
    called far more frequently than I'd expect.

¹ https://gitlab.com/qemu-project/qemu/-/commit/3634039b93cc5

Download attachment "smime.p7s" of type "application/pkcs7-signature" (5069 bytes)