summaryrefslogtreecommitdiffstats
diff options
context:
space:
mode:
authorHeiko Carstens <heiko.carstens@de.ibm.com>2015-07-07 08:40:49 +0200
committerMartin Schwidefsky <schwidefsky@de.ibm.com>2015-07-13 11:02:21 +0200
commitcad49cfc44a5160e3fa09b18e4e7f7cacd13f27d (patch)
tree6b3e99d4ea898161416c3780e48a4aebbefd2aab
parente47994dd44bcb4a77b4152bd0eada585934703c0 (diff)
downloadblackbird-obmc-linux-cad49cfc44a5160e3fa09b18e4e7f7cacd13f27d.tar.gz
blackbird-obmc-linux-cad49cfc44a5160e3fa09b18e4e7f7cacd13f27d.zip
s390/nmi: fix vector register corruption
If a machine check happens, the machine has the vector facility installed and the extended save area exists, the cpu will save vector register contents into the extended save area. This is regardless of control register 0 contents, which enables and disables the vector facility during runtime. On each machine check we should validate the vector registers. The current code however tries to validate the registers only if the running task is using vector registers in user space. However even the current code is broken and causes vector register corruption on machine checks, if user space uses them: the prefix area contains a pointer (absolute address) to the machine check extended save area. In order to save some space the save area was put into an unused area of the second prefix page. When validating vector register contents the code uses the absolute address of the extended save area, which is wrong. Due to prefixing the vector instructions will then access contents using absolute addresses instead of real addresses, where the machine stored the contents. If the above would work there is still the problem that register validition would only happen if user space uses vector registers. If kernel space uses them also, this may also lead to vector register content corruption: if the kernel makes use of vector instructions, but the current running user space context does not, the machine check handler will validate floating point registers instead of vector registers. Given the fact that writing to a floating point register may change the upper halve of the corresponding vector register, we also experience vector register corruption in this case. Fix all of these issues, and always validate vector registers on each machine check, if the machine has the vector facility installed and the extended save area is defined. Cc: <stable@vger.kernel.org> # 4.1+ Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com> Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
-rw-r--r--arch/s390/include/asm/ctl_reg.h5
-rw-r--r--arch/s390/kernel/nmi.c51
2 files changed, 34 insertions, 22 deletions
diff --git a/arch/s390/include/asm/ctl_reg.h b/arch/s390/include/asm/ctl_reg.h
index cfad7fca01d6..d7697ab802f6 100644
--- a/arch/s390/include/asm/ctl_reg.h
+++ b/arch/s390/include/asm/ctl_reg.h
@@ -57,7 +57,10 @@ union ctlreg0 {
unsigned long lap : 1; /* Low-address-protection control */
unsigned long : 4;
unsigned long edat : 1; /* Enhanced-DAT-enablement control */
- unsigned long : 23;
+ unsigned long : 4;
+ unsigned long afp : 1; /* AFP-register control */
+ unsigned long vx : 1; /* Vector enablement control */
+ unsigned long : 17;
};
};
diff --git a/arch/s390/kernel/nmi.c b/arch/s390/kernel/nmi.c
index 505c17c0ae1a..56b550893593 100644
--- a/arch/s390/kernel/nmi.c
+++ b/arch/s390/kernel/nmi.c
@@ -21,6 +21,7 @@
#include <asm/nmi.h>
#include <asm/crw.h>
#include <asm/switch_to.h>
+#include <asm/ctl_reg.h>
struct mcck_struct {
int kill_task;
@@ -129,26 +130,30 @@ static int notrace s390_revalidate_registers(struct mci *mci)
} else
asm volatile("lfpc 0(%0)" : : "a" (fpt_creg_save_area));
- asm volatile(
- " ld 0,0(%0)\n"
- " ld 1,8(%0)\n"
- " ld 2,16(%0)\n"
- " ld 3,24(%0)\n"
- " ld 4,32(%0)\n"
- " ld 5,40(%0)\n"
- " ld 6,48(%0)\n"
- " ld 7,56(%0)\n"
- " ld 8,64(%0)\n"
- " ld 9,72(%0)\n"
- " ld 10,80(%0)\n"
- " ld 11,88(%0)\n"
- " ld 12,96(%0)\n"
- " ld 13,104(%0)\n"
- " ld 14,112(%0)\n"
- " ld 15,120(%0)\n"
- : : "a" (fpt_save_area));
- /* Revalidate vector registers */
- if (MACHINE_HAS_VX && current->thread.vxrs) {
+ if (!MACHINE_HAS_VX) {
+ /* Revalidate floating point registers */
+ asm volatile(
+ " ld 0,0(%0)\n"
+ " ld 1,8(%0)\n"
+ " ld 2,16(%0)\n"
+ " ld 3,24(%0)\n"
+ " ld 4,32(%0)\n"
+ " ld 5,40(%0)\n"
+ " ld 6,48(%0)\n"
+ " ld 7,56(%0)\n"
+ " ld 8,64(%0)\n"
+ " ld 9,72(%0)\n"
+ " ld 10,80(%0)\n"
+ " ld 11,88(%0)\n"
+ " ld 12,96(%0)\n"
+ " ld 13,104(%0)\n"
+ " ld 14,112(%0)\n"
+ " ld 15,120(%0)\n"
+ : : "a" (fpt_save_area));
+ } else {
+ /* Revalidate vector registers */
+ union ctlreg0 cr0;
+
if (!mci->vr) {
/*
* Vector registers can't be restored and therefore
@@ -156,8 +161,12 @@ static int notrace s390_revalidate_registers(struct mci *mci)
*/
kill_task = 1;
}
+ cr0.val = S390_lowcore.cregs_save_area[0];
+ cr0.afp = cr0.vx = 1;
+ __ctl_load(cr0.val, 0, 0);
restore_vx_regs((__vector128 *)
- S390_lowcore.vector_save_area_addr);
+ &S390_lowcore.vector_save_area);
+ __ctl_load(S390_lowcore.cregs_save_area[0], 0, 0);
}
/* Revalidate access registers */
asm volatile(
OpenPOWER on IntegriCloud