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]
Date:   Thu, 01 Jun 2023 21:41:15 +0000
From:   Steven Noonan <steven@...inklabs.net>
To:     Peter Zijlstra <peterz@...radead.org>
Cc:     Thomas Gleixner <tglx@...utronix.de>,
        Muhammad Usama Anjum <usama.anjum@...labora.com>,
        Jonathan Corbet <corbet@....net>,
        Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>,
        Dave Hansen <dave.hansen@...ux.intel.com>,
        "maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT)" <x86@...nel.org>,
        "H. Peter Anvin" <hpa@...or.com>,
        "open list:DOCUMENTATION" <linux-doc@...r.kernel.org>,
        open list <linux-kernel@...r.kernel.org>,
        "Guilherme G. Piccoli" <gpiccoli@...lia.com>, kernel@...labora.com
Subject: Re: Direct rdtsc call side-effect

On Thursday, June 1st, 2023 at 1:31 PM, Peter Zijlstra <peterz@...radead.org> wrote:
> What about kernel based emulation? You could tie it into user_dispatch
> and have a user_dispatch tsc offset.
> 

> So regular kernel emulation simply returns the native value (keeps the
> VDSO working for one), but then from a user_dispatch range, it returns
> +offset.
> 

> That is; how slow is the below?

It's around 1800-1900 clock cycles on this system (modified patch attached, compile fix + rdtscp support).

It's definitely better than the userspace signal handler (20x vs 100x). Also compared to reading one of the clock_gettime() clocks when current_clocksource is 'hpet', it's about twice as fast. So that's at least in the realm of being usable.

Since faulting would still make the vDSO clocks go through this path we'd have to be careful that whatever offsets we throw into this path don't affect the correctness of the other clocks.
Download attachment "tsc-test.patch" of type "application/octet-stream" (1291 bytes)

Download attachment "signature.asc" of type "application/pgp-signature" (250 bytes)

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ