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: <20230602064515.GA620383@hirez.programming.kicks-ass.net>
Date:   Fri, 2 Jun 2023 08:45:15 +0200
From:   Peter Zijlstra <peterz@...radead.org>
To:     Steven Noonan <steven@...inklabs.net>
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 Thu, Jun 01, 2023 at 09:41:15PM +0000, Steven Noonan wrote:
> 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 

Much more expensive than the actual instruction ofcourse, but that seems
eminently usable.

> (modified patch attached, compile fix + rdtscp support).

Right, that's what I get for writing 'patches' while falling asleep :/

> 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.

Hence the suggested tie-in with user-dispatch; only add the offset when
the IP is from the user-dispatch range.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ