Received: by 2002:a5b:505:0:0:0:0:0 with SMTP id o5csp1227108ybp; Fri, 4 Oct 2019 11:20:44 -0700 (PDT) X-Google-Smtp-Source: APXvYqxSlTToBqDpXV1aG7+y1KlyLE1crUMC5Q2FBP8cDPFYdDC7WpB6yt3jNSZO+pvVaCwm7//6 X-Received: by 2002:a17:906:1e57:: with SMTP id i23mr13639857ejj.204.1570213244443; Fri, 04 Oct 2019 11:20:44 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1570213244; cv=none; d=google.com; s=arc-20160816; b=ITujmTAcfiI+Kci4noeRYDTFQEgyHVfUdEjqX+ugdzpJ+8iukjqa+gwdzs9ze8QTVd WsQjf4XYOEDR1ghySQkQ3+jqyVEEk6EI4jI6zuCh7GFk7kHC80rh032w1iIFK5RFeKlB YNxA0AZ4TZDpVACpIns1M4SZ9ZVr9oitylmzteFN/7PZNqdrfomwksQ/DGcuNiKE8dh3 rdpRxeqEOoWa+hizBfmSajpaZNCuSbyPSeBcbHXfjNBpX8U3fTwprMOJLar6QPoymrPh JKBPG6KDQp3vugV53AgVPdX7Mhk1DCkBCu/FUZhtM9PjEKnorpi9emAhHao37ACS55TT WgAA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:references:in-reply-to:message-id:date :subject:cc:to:from; bh=uS4tsxuutvk52epE+oCL/Ftr6dNONzoi11Cj1s1FxJQ=; b=tUDLc7mBoEjn+wA0jZ3ogj84N/YMw/y5WLnUKCJXzyJ50V7FhYU79H+jDFc73H3gDk GPi6ElAyx1+sZaaz8P/0PBzNWRF+aCGHpKYnTQqtYEXX9zSyX1hFKlap7opbrVvKbTon KBtEJf1vK0vZAyvBWnYCEXjwjXJak7gQXcDwakWxqVZ0bSoxjlIwrkP/QbEtBHm7UlJD 1dFoMK3a5GWDn/qql+9mVpZY4mFa04c5RQJcmECmaWgz+Aw+3sKvEW/2fJ/cc9d5alnd PMkdPJmtfEVcsaeXRJgcnwkvBA8tffpF/CkwmW65gjjyIvhFipIN+/urQTyFlJSFyA7s 2j1w== 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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id f45si4039349eda.345.2019.10.04.11.20.20; Fri, 04 Oct 2019 11:20:44 -0700 (PDT) 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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1730661AbfJDSR7 (ORCPT + 99 others); Fri, 4 Oct 2019 14:17:59 -0400 Received: from mga07.intel.com ([134.134.136.100]:15508 "EHLO mga07.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1730157AbfJDSQ7 (ORCPT ); Fri, 4 Oct 2019 14:16:59 -0400 X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga002.jf.intel.com ([10.7.209.21]) by orsmga105.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 04 Oct 2019 11:16:58 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.67,257,1566889200"; d="scan'208";a="204394742" Received: from chang-linux-3.sc.intel.com ([172.25.66.185]) by orsmga002.jf.intel.com with ESMTP; 04 Oct 2019 11:16:58 -0700 From: "Chang S. Bae" To: linux-kernel@vger.kernel.org, tglx@linutronix.de, bp@alien8.de, luto@kernel.org Cc: hpa@zytor.com, dave.hansen@intel.com, tony.luck@intel.com, ak@linux.intel.com, ravi.v.shankar@intel.com, chang.seok.bae@intel.com Subject: [PATCH v9 01/17] x86/ptrace: Prevent ptrace from clearing the FS/GS selector Date: Fri, 4 Oct 2019 11:15:53 -0700 Message-Id: <1570212969-21888-2-git-send-email-chang.seok.bae@intel.com> X-Mailer: git-send-email 2.7.4 In-Reply-To: <1570212969-21888-1-git-send-email-chang.seok.bae@intel.com> References: <1570212969-21888-1-git-send-email-chang.seok.bae@intel.com> Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org When a ptracer writes a ptracee's FS/GS base with a different value, the selector is also cleared. This behavior is not correct as the selector should be preserved. Update only the base value and leave the selector intact. To simplify the code further remove the conditional checking for the same value as this code is not performance-critical. The only recognizable downside of this change is when the selector is already nonzero on write. The base will be reloaded according to the selector. But the case is highly unexpected in real usages. Suggested-by: Andy Lutomirski Signed-off-by: Chang S. Bae Reviewed-by: Tony Luck Cc: Thomas Gleixner Cc: Borislav Petkov Cc: Andy Lutomirski Cc: H. Peter Anvin Cc: Dave Hansen Cc: Tony Luck Cc: Andi Kleen --- Changes from v8: none Changes from v7: * Fixed to call correct helper functions * Massaged changelog by Thomas * Used '[FS|GS] base' consistently, instead of '[FS|GS]BASE' --- arch/x86/kernel/ptrace.c | 14 ++------------ 1 file changed, 2 insertions(+), 12 deletions(-) diff --git a/arch/x86/kernel/ptrace.c b/arch/x86/kernel/ptrace.c index 3c5bbe8..df222e2 100644 --- a/arch/x86/kernel/ptrace.c +++ b/arch/x86/kernel/ptrace.c @@ -370,22 +370,12 @@ static int putreg(struct task_struct *child, case offsetof(struct user_regs_struct,fs_base): if (value >= TASK_SIZE_MAX) return -EIO; - /* - * When changing the FS base, use do_arch_prctl_64() - * to set the index to zero and to set the base - * as requested. - */ - if (child->thread.fsbase != value) - return do_arch_prctl_64(child, ARCH_SET_FS, value); + x86_fsbase_write_task(child, value); return 0; case offsetof(struct user_regs_struct,gs_base): - /* - * Exactly the same here as the %fs handling above. - */ if (value >= TASK_SIZE_MAX) return -EIO; - if (child->thread.gsbase != value) - return do_arch_prctl_64(child, ARCH_SET_GS, value); + x86_gsbase_write_task(child, value); return 0; #endif } -- 2.7.4