linux-kernel - Re: Direct rdtsc call side-effect

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: <YveIgyZYN48CEPKlxf6r_CfVBGuON83brWVxnVJGtXW70bDprPOiAtEMeKELDJj3lVYuZm7fTDQnMIuheMN01YfqfWbCGYia0uWcWIx59oM=@uplinklabs.net>
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)