Arvind Sankar aa5cacdc29 x86/asm: Replace __force_order with a memory clobber ... 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. Signed-off-by: Arvind Sankar <nivedita@alum.mit.edu> Signed-off-by: Borislav Petkov <bp@suse.de> Reviewed-by: Kees Cook <keescook@chromium.org> Reviewed-by: Miguel Ojeda <miguel.ojeda.sandonis@gmail.com> Tested-by: Nathan Chancellor <natechancellor@gmail.com> Tested-by: Sedat Dilek <sedat.dilek@gmail.com> Link: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82602 Link: https://lore.kernel.org/lkml/20200527135329.1172644-1-arnd@arndb.de/ Link: https://lkml.kernel.org/r/20200902232152.3709896-1-nivedita@alum.mit.edu		2020-10-01 10:31:48 +02:00
..
alpha	treewide: Use fallthrough pseudo-keyword	2020-08-23 17:36:59 -05:00
arc	treewide: Use fallthrough pseudo-keyword	2020-08-23 17:36:59 -05:00
arm	A set of fixes for lockdep, tracing and RCU:	2020-08-30 11:43:50 -07:00
arm64	A set of fixes for interrupt chip drivers:	2020-08-30 11:56:54 -07:00
c6x	treewide: Use fallthrough pseudo-keyword	2020-08-23 17:36:59 -05:00
csky	treewide: Use fallthrough pseudo-keyword	2020-08-23 17:36:59 -05:00
h8300	treewide: Use fallthrough pseudo-keyword	2020-08-23 17:36:59 -05:00
hexagon	treewide: Use fallthrough pseudo-keyword	2020-08-23 17:36:59 -05:00
ia64	treewide: Use fallthrough pseudo-keyword	2020-08-23 17:36:59 -05:00
m68k	treewide: Use fallthrough pseudo-keyword	2020-08-23 17:36:59 -05:00
microblaze	treewide: Use fallthrough pseudo-keyword	2020-08-23 17:36:59 -05:00
mips	A set of fixes for lockdep, tracing and RCU:	2020-08-30 11:43:50 -07:00
nds32	A set of fixes for lockdep, tracing and RCU:	2020-08-30 11:43:50 -07:00
nios2	mm/nios2: use general page fault accounting	2020-08-12 10:58:03 -07:00
openrisc	treewide: Use fallthrough pseudo-keyword	2020-08-23 17:36:59 -05:00
parisc	treewide: Use fallthrough pseudo-keyword	2020-08-23 17:36:59 -05:00
powerpc	A set of fixes for lockdep, tracing and RCU:	2020-08-30 11:43:50 -07:00
riscv	treewide: Use fallthrough pseudo-keyword	2020-08-23 17:36:59 -05:00
s390	A set of fixes for lockdep, tracing and RCU:	2020-08-30 11:43:50 -07:00
sh	treewide: Use fallthrough pseudo-keyword	2020-08-23 17:36:59 -05:00
sparc	treewide: Use fallthrough pseudo-keyword	2020-08-23 17:36:59 -05:00
um	treewide: Use fallthrough pseudo-keyword	2020-08-23 17:36:59 -05:00
x86	x86/asm: Replace __force_order with a memory clobber	2020-10-01 10:31:48 +02:00
xtensa	treewide: Use fallthrough pseudo-keyword	2020-08-23 17:36:59 -05:00
.gitignore
Kconfig	A set oftimekeeping/VDSO updates:	2020-08-14 14:26:08 -07:00