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  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:   Sat, 22 Aug 2020 17:10:21 -0700
From:   Linus Torvalds <>
To:     Arvind Sankar <>
Cc:     Miguel Ojeda <>,
        Sedat Dilek <>,
        Segher Boessenkool <>,
        Thomas Gleixner <>,
        Nick Desaulniers <>,
        "Paul E. McKenney" <>,
        Ingo Molnar <>, Arnd Bergmann <>,
        Borislav Petkov <>,
        "maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT)" <>,
        "H. Peter Anvin" <>,
        "Kirill A. Shutemov" <>,
        Zhenzhong Duan <>,
        Kees Cook <>,
        Peter Zijlstra <>,
        Juergen Gross <>,
        Andy Lutomirski <>,
        Andrew Cooper <>,
        LKML <>,
        clang-built-linux <>,
        Will Deacon <>
Subject: Re: [PATCH] x86: work around clang IAS bug referencing __force_order

On Sat, Aug 22, 2020 at 4:11 PM Arvind Sankar <> wrote:
> Actually, is a memory clobber required for correctness? Memory accesses
> probably shouldn't be reordered across a CRn write. Is asm volatile
> enough to stop that or do you need a memory clobber?

You do need a memory clobber if you really care about ordering wrt
normal memory references.

That said, I'm not convinced we do care here. Normal memory accesses
(as seen by the compiler) should be entirely immune to any changes we
do wrt CRx registers.

Because code that really fundamentally changes kernel mappings or
access rules is already written in low-level assembler (eg the entry
routines or bootup).

Anything that relies on the more subtle changes (ie user space
accesses etc) should already be ordered by other things - usually by
the fact that they are also "asm volatile".

But hey, maybe somebody can come up with an exception to that.


Powered by blists - more mailing lists