Buildresult: powerpc-fixes/arm64-defconfig/arm64-gcc5 built on Sep 5 2019, 00:06

kisskb

Revisions | Branches | Compilers | Configs | Build Results | Build Failures |

Status:	OK
Date/Time:	Sep 5 2019, 00:06
Duration:	0:04:54.278945
Builder:	ka1
Revision:	powerpc/tm: Fix restoring FP/VMX facility incorrectly on interrupts (`a8318c13e79badb92bc6640704a64cc022a6eb97)`
Target:	powerpc-fixes/arm64-defconfig/arm64-gcc5
Branch:	powerpc-fixes
Compiler:	arm64-gcc5 (aarch64-linux-gcc.br_real (Buildroot 2016.11-git-00613-ge98b4dd) 5.4.0 / GNU ld (GNU Binutils) 2.25.1)
Config:	defconfig (download)
Log:	Download original Possible warnings (2) drivers/i2c/busses/i2c-sh_mobile.c:399:26: warning: 'data' may be used uninitialized in this function [-Wmaybe-uninitialized] include/linux/spinlock.h:288:3: warning: 'flags' may be used uninitialized in this function [-Wmaybe-uninitialized] Full Log # git rev-parse -q --verify a8318c13e79badb92bc6640704a64cc022a6eb97^{commit} a8318c13e79badb92bc6640704a64cc022a6eb97 already have revision, skipping fetch # git checkout -q -f -B kisskb a8318c13e79badb92bc6640704a64cc022a6eb97 # git clean -qxdf # < git log -1 # commit a8318c13e79badb92bc6640704a64cc022a6eb97 # Author: Gustavo Romero <gromero@linux.ibm.com> # Date: Wed Sep 4 00:55:28 2019 -0400 # # powerpc/tm: Fix restoring FP/VMX facility incorrectly on interrupts # # When in userspace and MSR FP=0 the hardware FP state is unrelated to # the current process. This is extended for transactions where if tbegin # is run with FP=0, the hardware checkpoint FP state will also be # unrelated to the current process. Due to this, we need to ensure this # hardware checkpoint is updated with the correct state before we enable # FP for this process. # # Unfortunately we get this wrong when returning to a process from a # hardware interrupt. A process that starts a transaction with FP=0 can # take an interrupt. When the kernel returns back to that process, we # change to FP=1 but with hardware checkpoint FP state not updated. If # this transaction is then rolled back, the FP registers now contain the # wrong state. # # The process looks like this: # Userspace: Kernel # # Start userspace # with MSR FP=0 TM=1 # < ----- # ... # tbegin # bne # Hardware interrupt # ---- > # <do_IRQ...> # .... # ret_from_except # restore_math() # /* sees FP=0 / # restore_fp() # tm_active_with_fp() # / sees FP=1 (Incorrect) */ # load_fp_state() # FP = 0 -> 1 # < ----- # Return to userspace # with MSR TM=1 FP=1 # with junk in the FP TM checkpoint # TM rollback # reads FP junk # # When returning from the hardware exception, tm_active_with_fp() is # incorrectly making restore_fp() call load_fp_state() which is setting # FP=1. # # The fix is to remove tm_active_with_fp(). # # tm_active_with_fp() is attempting to handle the case where FP state # has been changed inside a transaction. In this case the checkpointed # and transactional FP state is different and hence we must restore the # FP state (ie. we can't do lazy FP restore inside a transaction that's # used FP). It's safe to remove tm_active_with_fp() as this case is # handled by restore_tm_state(). restore_tm_state() detects if FP has # been using inside a transaction and will set load_fp and call # restore_math() to ensure the FP state (checkpoint and transaction) is # restored. # # This is a data integrity problem for the current process as the FP # registers are corrupted. It's also a security problem as the FP # registers from one process may be leaked to another. # # Similarly for VMX. # # A simple testcase to replicate this will be posted to # tools/testing/selftests/powerpc/tm/tm-poison.c # # This fixes CVE-2019-15031. # # Fixes: a7771176b439 ("powerpc: Don't enable FP/Altivec if not checkpointed") # Cc: stable@vger.kernel.org # 4.15+ # Signed-off-by: Gustavo Romero <gromero@linux.ibm.com> # Signed-off-by: Michael Neuling <mikey@neuling.org> # Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> # Link: https://lore.kernel.org/r/20190904045529.23002-2-gromero@linux.vnet.ibm.com # < /opt/cross/kisskb/br-aarch64-glibc-2016.08-613-ge98b4dd/bin/aarch64-linux-gcc --version # < /opt/cross/kisskb/br-aarch64-glibc-2016.08-613-ge98b4dd/bin/aarch64-linux-ld --version # < git log --format=%s --max-count=1 a8318c13e79badb92bc6640704a64cc022a6eb97 # < make -s -j 48 ARCH=arm64 O=/kisskb/build/powerpc-fixes_arm64-defconfig_arm64-gcc5.4 CROSS_COMPILE=/opt/cross/kisskb/br-aarch64-glibc-2016.08-613-ge98b4dd/bin/aarch64-linux- defconfig # make -s -j 48 ARCH=arm64 O=/kisskb/build/powerpc-fixes_arm64-defconfig_arm64-gcc5.4 CROSS_COMPILE=/opt/cross/kisskb/br-aarch64-glibc-2016.08-613-ge98b4dd/bin/aarch64-linux- arch/arm64/Makefile:27: ld does not support --fix-cortex-a53-843419; kernel may be susceptible to erratum arch/arm64/Makefile:38: LSE atomics not supported by binutils arch/arm64/Makefile:56: CROSS_COMPILE_COMPAT not defined or empty, the compat vDSO will not be built /kisskb/src/drivers/i2c/busses/i2c-sh_mobile.c: In function 'sh_mobile_i2c_isr': /kisskb/src/drivers/i2c/busses/i2c-sh_mobile.c:399:26: warning: 'data' may be used uninitialized in this function [-Wmaybe-uninitialized] pd->msg->buf[real_pos] = data; ^ /kisskb/src/drivers/i2c/busses/i2c-sh_mobile.c:372:16: note: 'data' was declared here unsigned char data; ^ In file included from /kisskb/src/include/linux/rwsem.h:16:0, from /kisskb/src/include/linux/notifier.h:15, from /kisskb/src/include/linux/clk.h:14, from /kisskb/src/drivers/tty/serial/sh-sci.c:24: /kisskb/src/drivers/tty/serial/sh-sci.c: In function 'sci_dma_rx_submit': /kisskb/src/include/linux/spinlock.h:288:3: warning: 'flags' may be used uninitialized in this function [-Wmaybe-uninitialized] _raw_spin_unlock_irqrestore(lock, flags); \ ^ /kisskb/src/drivers/tty/serial/sh-sci.c:1353:16: note: 'flags' was declared here unsigned long flags; ^ Completed OK # rm -rf /kisskb/build/powerpc-fixes_arm64-defconfig_arm64-gcc5.4 # Build took: 0:04:54.278945

© Michael Ellerman 2006-2018.