[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <202009021916.CD41C28A52@keescook>
Date: Wed, 2 Sep 2020 19:17:30 -0700
From: Kees Cook <keescook@...omium.org>
To: Arvind Sankar <nivedita@...m.mit.edu>
Cc: Linus Torvalds <torvalds@...ux-foundation.org>,
Miguel Ojeda <miguel.ojeda.sandonis@...il.com>,
Sedat Dilek <sedat.dilek@...il.com>,
Segher Boessenkool <segher@...nel.crashing.org>,
Thomas Gleixner <tglx@...utronix.de>,
Nick Desaulniers <ndesaulniers@...gle.com>,
"Paul E. McKenney" <paulmck@...nel.org>,
Ingo Molnar <mingo@...hat.com>, Arnd Bergmann <arnd@...db.de>,
Borislav Petkov <bp@...en8.de>,
"maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT)" <x86@...nel.org>,
"H. Peter Anvin" <hpa@...or.com>,
"Kirill A. Shutemov" <kirill.shutemov@...ux.intel.com>,
Peter Zijlstra <peterz@...radead.org>,
Juergen Gross <jgross@...e.com>,
Andy Lutomirski <luto@...nel.org>,
Andrew Cooper <andrew.cooper3@...rix.com>,
LKML <linux-kernel@...r.kernel.org>,
clang-built-linux <clang-built-linux@...glegroups.com>,
Will Deacon <will@...nel.org>, nadav.amit@...il.com,
Nathan Chancellor <natechancellor@...il.com>
Subject: Re: [PATCH v3] x86/asm: Replace __force_order with memory clobber
On Wed, Sep 02, 2020 at 07:21:52PM -0400, Arvind Sankar wrote:
> The CRn accessor functions use __force_order as a dummy operand to
> prevent the compiler from reordering CRn reads/writes with respect to
> each other.
>
> The fact that the asm is volatile should be enough to prevent this:
> volatile asm statements should be executed in program order. However GCC
> 4.9.x and 5.x have a bug that might result in reordering. This was fixed
> in 8.1, 7.3 and 6.5. Versions prior to these, including 5.x and 4.9.x,
> may reorder volatile asm statements with respect to each other.
>
> There are some issues with __force_order as implemented:
> - It is used only as an input operand for the write functions, and hence
> doesn't do anything additional to prevent reordering writes.
> - It allows memory accesses to be cached/reordered across write
> functions, but CRn writes affect the semantics of memory accesses, so
> this could be dangerous.
> - __force_order is not actually defined in the kernel proper, but the
> LLVM toolchain can in some cases require a definition: LLVM (as well
> as GCC 4.9) requires it for PIE code, which is why the compressed
> kernel has a definition, but also the clang integrated assembler may
> consider the address of __force_order to be significant, resulting in
> a reference that requires a definition.
>
> Fix this by:
> - Using a memory clobber for the write functions to additionally prevent
> caching/reordering memory accesses across CRn writes.
> - Using a dummy input operand with an arbitrary constant address for the
> read functions, instead of a global variable. This will prevent reads
> from being reordered across writes, while allowing memory loads to be
> cached/reordered across CRn reads, which should be safe.
>
> Tested-by: Nathan Chancellor <natechancellor@...il.com>
> Tested-by: Sedat Dilek <sedat.dilek@...il.com>
> Signed-off-by: Arvind Sankar <nivedita@...m.mit.edu>
Seems reasonable to me. As reasonable as compiler bug workarounds
go, that is. ;)
Reviewed-by: Kees Cook <keescook@...omium.org>
--
Kees Cook
Powered by blists - more mailing lists