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: <007a7132d1396912b1381e96cc4401a10071ed24.camel@sipsolutions.net>
Date: Wed, 07 May 2025 22:36:30 +0200
From: Johannes Berg <johannes@...solutions.net>
To: "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>, 
 "linux-tip-commits@...r.kernel.org"
	 <linux-tip-commits@...r.kernel.org>
Cc: lkp <lkp@...el.com>, Ingo Molnar <mingo@...nel.org>, "x86@...nel.org"
	 <x86@...nel.org>, linux-um@...ts.infradead.org
Subject: Re: [tip: x86/msr] um: Add UML version of <asm/tsc.h> to define
 rdtsc()

+linux-um

On Wed, 2025-05-07 at 18:40 +0000, tip-bot2 for Ingo Molnar wrote:
> 
> To resolve these kinds of problems and to allow <asm/tsc.h> to be included on UML,
> add a simplified version of <asm/tsc.h>, which only adds the rdtsc() definition.

OK, weird, why would that be needed - UM isn't really X86.

>  arch/um/include/asm/tsc.h | 25 +++++++++++++++++++++++++

Feels that should be in arch/x86/um/asm/ instead, which I believe is
also included but then at least pretends to keep the notion that UML
could be ported to other architectures ;-)

> +static __always_inline u64 rdtsc(void)
> +{
> +       EAX_EDX_DECLARE_ARGS(val, low, high);
> +
> +       asm volatile("rdtsc" : EAX_EDX_RET(val, low, high));
> +
> +       return EAX_EDX_VAL(val, low, high);
> +}

Though I also wonder where this is called at all that would be relevant
for UML? If it's not then perhaps we should just make using it
unbuildable, a la

u64 __um_has_no_rdtsc(void);
#define rdtsc() __um_has_no_rdtsc()

or something like that... (and then of course keep it in the current
location). But looking at the 0-day report that'd probably break
building the driver on UML; while the driver doesn't seem important we
wouldn't really want that...

Actually, that's just because of the stupid quirk in UML/X86:

config DRM_ACCEL_HABANALABS
        tristate "HabanaLabs AI accelerators"
        depends on DRM_ACCEL
        depends on X86_64

that last line should almost certainly be "depends on X86 && X86_64"
because ARCH=um will set UM and X86_64, but not X86 since the arch
Kconfig symbols are X86 and UM respectively, but the UML subarch still
selects X86_64 ...


I dunno. I guess we can put rdtsc() into UML on x86 as I suggested about
the file placement, or we can also just fix the Kconfig there.

johannes

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ