linux-kernel - Re: [PATCH 1/1] x86: In x86-64 barrier

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <119B5F1F-7319-4C28-8A91-EB570BF5ABEB@zytor.com>
Date: Sun, 09 Feb 2025 18:15:35 -0800
From: "H. Peter Anvin" <hpa@...or.com>
To: Rik van Riel <riel@...riel.com>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        David Laight <david.laight.linux@...il.com>
CC: x86@...nel.org, linux-kernel@...r.kernel.org,
        Thomas Gleixner <tglx@...utronix.de>, Ingo Molnar <mingo@...hat.com>,
        Borislav Petkov <bp@...en8.de>,
        Dave Hansen <dave.hansen@...ux.intel.com>,
        Catalin Marinas <catalin.marinas@....com>,
        Mathieu Desnoyers <mathieu.desnoyers@...icios.com>,
        Josh Poimboeuf <jpoimboe@...hat.com>, Andi Kleen <ak@...ux.intel.com>,
        Dan Williams <dan.j.williams@...el.com>, linux-arch@...r.kernel.org,
        Kees Cook <keescook@...omium.org>, kernel-hardening@...ts.openwall.com,
        "Paul E.McKenney" <paulmck@...nel.org>
Subject: Re: [PATCH 1/1] x86: In x86-64 barrier_nospec can always be lfence

On February 9, 2025 5:09:51 PM PST, Rik van Riel <riel@...riel.com> wrote:
>On Sun, 2025-02-09 at 13:57 -0800, Linus Torvalds wrote:
>> 
>> So on x86, both read and write barriers are complete no-ops, because
>> all reads are ordered, and all writes are ordered.
>
>Given that this thread started with a reference
>to rdtsc, it may be worth keeping in mind that
>rdtsc reads themselves do not always appear to
>be ordered.
>
>Paul and I spotted some occasionaly "backwards
>TSC values" from the CSD lock instrumentation code, 
>which went away when using ordered TSC reads:
>
>https://lkml.iu.edu/hypermail/linux/kernel/2410.1/03202.html
>
>I guess maybe a TSC read does not follow all the same
>rules as a memory read, sometimes?
>

It probably doesn't, at least on uarches.