Received: by 10.223.185.116 with SMTP id b49csp6376964wrg; Wed, 28 Feb 2018 08:24:43 -0800 (PST) X-Google-Smtp-Source: AH8x225vpvqMFRpb/I8NZEOS4w3rPkQJvtjf1c/bHH1Fsl20bLz7vxVo5MV8H4zC9sl82K0pTd0D X-Received: by 2002:a17:902:2863:: with SMTP id e90-v6mr18604756plb.232.1519835083593; Wed, 28 Feb 2018 08:24:43 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1519835083; cv=none; d=google.com; s=arc-20160816; b=anreCc4EQHZplmmaix0Mj1KX6J0SKwk3aOZn/S5THoJ5iqu3KVt89/1vTdtM7fWL5k RJEYL62pkqMm6YV5kDc4WxZ4tUqGMzl40n36qIFWqWNN9o9Gz1qLY/tQC2HUDDyGW1M3 bsDgVBDW8ofyi1Sg1OWNfqybWywhyHIG4nCCMQUEAHXb5G9pWtdIE2ivpbwNEA8xM1tU 3HUJW9u5GeVGwIIA68IS/OHZLK+5xl2DfyCu+740Qh7rBjzKplW5KBMRC4ZrB+K9Uyva A+1dmAZCf3e4xdfuuAHoT32iY++GeKiHGgT+u/Z0AS1IuClRMEr8+HjyrLDFiuY74zmU DMWQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:in-reply-to:subject:message-id:date:cc:to :from:mime-version:content-transfer-encoding:content-disposition :arc-authentication-results; bh=6wvXrxdPAO7ff/fGK779wataCw/j3pyzFvLElM7t1m0=; b=mKBN7e1tyvGrzYOtM7v+sSu/NbUKplhS7dTr+eThyTiabk7TIAx4ircp+DK6nUuiO3 WWULtTPdAbissVXI0mKI6tVGfvnJ1KuKPlV0FSPc1IKgy7OKfKWMUU++YISIG/h/0e/K CGfT8tEFd0SyD/RfPXO1bWXsk/f5eNTCp4dOypv+hJctdK/WrdnW8Q/ROudiCb7UCkaW jPyHQsc1a0TJPCxbWZfD88t9eeF72WXKZfOYv/IogN98n9qkPB9cmLK61xSyAhwQbke1 oHCE7Kf1GfW7sWLQoL4yNFNDbbcFYI+nz7z9kbla0IJqUcmA6OAiWxL1SpdSOF1Xo9CQ eSfA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id p9si1140693pgc.685.2018.02.28.08.24.28; Wed, 28 Feb 2018 08:24:43 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S934852AbeB1QXw (ORCPT + 99 others); Wed, 28 Feb 2018 11:23:52 -0500 Received: from shadbolt.e.decadent.org.uk ([88.96.1.126]:35385 "EHLO shadbolt.e.decadent.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S935062AbeB1QUq (ORCPT ); Wed, 28 Feb 2018 11:20:46 -0500 Received: from [2a02:8011:400e:2:6f00:88c8:c921:d332] (helo=deadeye) by shadbolt.decadent.org.uk with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1er3Ys-0006XU-UB; Wed, 28 Feb 2018 15:22:31 +0000 Received: from ben by deadeye with local (Exim 4.90_1) (envelope-from ) id 1er3Yg-000058-D0; Wed, 28 Feb 2018 15:22:18 +0000 Content-Type: text/plain; charset="UTF-8" Content-Disposition: inline Content-Transfer-Encoding: 8bit MIME-Version: 1.0 From: Ben Hutchings To: linux-kernel@vger.kernel.org, stable@vger.kernel.org CC: akpm@linux-foundation.org, linux-mips@linux-mips.org, "Maciej W. Rozycki" , "Ralf Baechle" Date: Wed, 28 Feb 2018 15:20:18 +0000 Message-ID: X-Mailer: LinuxStableQueue (scripts by bwh) Subject: [PATCH 3.16 103/254] MIPS: ptrace: Prevent writes to read-only FCSR bits In-Reply-To: X-SA-Exim-Connect-IP: 2a02:8011:400e:2:6f00:88c8:c921:d332 X-SA-Exim-Mail-From: ben@decadent.org.uk X-SA-Exim-Scanned: No (on shadbolt.decadent.org.uk); SAEximRunCond expanded to false Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 3.16.55-rc1 review patch. If anyone has any objections, please let me know. ------------------ From: "Maciej W. Rozycki" commit abf378be49f38c4d3e23581d3df3fa9f1b1b11d2 upstream. Correct the cases missed with commit 9b26616c8d9d ("MIPS: Respect the ISA level in FCSR handling") and prevent writes to read-only FCSR bits there. This in particular applies to FP context initialisation where any IEEE 754-2008 bits preset by `mips_set_personality_nan' are cleared before the relevant ptrace(2) call takes effect and the PTRACE_POKEUSR request addressing FPC_CSR where no masking of read-only FCSR bits is done. Remove the FCSR clearing from FP context initialisation then and unify PTRACE_POKEUSR/FPC_CSR and PTRACE_SETFPREGS handling, by factoring out code from `ptrace_setfpregs' and calling it from both places. This mostly matters to soft float configurations where the emulator can be switched this way to a mode which should not be accessible and cannot be set with the CTC1 instruction. With hard float configurations any effect is transient anyway as read-only bits will retain their values at the time the FP context is restored. Signed-off-by: Maciej W. Rozycki Cc: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/13239/ Signed-off-by: Ralf Baechle [bwh: Backported to 3.16: There is no mips_set_personality_nan(), so make init_fp_ctx() copy the initial value of FCSR31] Signed-off-by: Ben Hutchings --- --- a/arch/mips/kernel/ptrace.c +++ b/arch/mips/kernel/ptrace.c @@ -57,8 +57,7 @@ static void init_fp_ctx(struct task_stru /* Begin with data registers set to all 1s... */ memset(&target->thread.fpu.fpr, ~0, sizeof(target->thread.fpu.fpr)); - /* ...and FCSR zeroed */ - target->thread.fpu.fcr31 = 0; + target->thread.fpu.fcr31 = boot_cpu_data.fpu_csr31; /* * Record that the target has "used" math, such that the context @@ -80,6 +79,22 @@ void ptrace_disable(struct task_struct * } /* + * Poke at FCSR according to its mask. Don't set the cause bits as + * this is currently not handled correctly in FP context restoration + * and will cause an oops if a corresponding enable bit is set. + */ +static void ptrace_setfcr31(struct task_struct *child, u32 value) +{ + u32 fcr31; + u32 mask; + + value &= ~FPU_CSR_ALL_X; + fcr31 = child->thread.fpu.fcr31; + mask = boot_cpu_data.fpu_msk31; + child->thread.fpu.fcr31 = (value & ~mask) | (fcr31 & mask); +} + +/* * Read a general register set. We always use the 64-bit format, even * for 32-bit kernels and for 32-bit processes on a 64-bit kernel. * Registers are sign extended to fill the available space. @@ -159,9 +174,7 @@ int ptrace_setfpregs(struct task_struct { union fpureg *fregs; u64 fpr_val; - u32 fcr31; u32 value; - u32 mask; int i; if (!access_ok(VERIFY_READ, data, 33 * 8)) @@ -176,10 +189,7 @@ int ptrace_setfpregs(struct task_struct } __get_user(value, data + 64); - value &= ~FPU_CSR_ALL_X; - fcr31 = child->thread.fpu.fcr31; - mask = boot_cpu_data.fpu_msk31; - child->thread.fpu.fcr31 = (value & ~mask) | (fcr31 & mask); + ptrace_setfcr31(child, value); /* FIR may not be written. */ @@ -739,7 +749,7 @@ long arch_ptrace(struct task_struct *chi break; #endif case FPC_CSR: - child->thread.fpu.fcr31 = data & ~FPU_CSR_ALL_X; + ptrace_setfcr31(child, data); break; case DSP_BASE ... DSP_BASE + 5: { dspreg_t *dregs;