Received: by 2002:ac0:a594:0:0:0:0:0 with SMTP id m20-v6csp1983590imm; Tue, 22 May 2018 12:38:06 -0700 (PDT) X-Google-Smtp-Source: AB8JxZoS2vjglXgxjxdIW6833jN46Tt2ZsxgnE/kXe7udJyksd/4jKyVHQI6L+pqOZiC5UIGRash X-Received: by 2002:a63:ab05:: with SMTP id p5-v6mr19569132pgf.387.1527017886435; Tue, 22 May 2018 12:38:06 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1527017886; cv=none; d=google.com; s=arc-20160816; b=Xw5JAmCn7dKBX8WiQ+ilj4bMuQESVX7Z8GMOgJm9lNrO5bqi3DM3uS1FbXdP4hSgzz +IxoEfM6jzdJyGwzG8a5KsTPvLCuaWTySoHf+tv+VC0NS5hLgLwQr5kUH6I5gL4ijZ5K 5s5jRcat5ULpHVsWDfb6KdvYzWnkoYiYvsXFolPib8YbktU9UVvGmwlmz2UxmkULiH+u Cir2SlIXd0dPBoCj3FsFHCnhR4zF0HLqfMStAkOVfnNssxMrDaRifiag3OAoM6/rUbJd 4HqC0G5xRF8YSkR5C02BWT50HWEldGvM47VpfPh7LTDA+HC3lAOrNOgUVRIHIvtFAK75 qdkQ== 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:references :in-reply-to:message-id:date:subject:cc:to:from :arc-authentication-results; bh=uentds7GH+tbnk7XcN79Viw/3LPakYY/+Z7+Tbz6l4k=; b=NZwbH2uu7JMptb2flltlZCpN9lFOz88U2KDul1ijU4aGyGy79iug52ZMlB8m6ExNHV 5YK8jUyQ3err9j+CSubXws24YNkAt2ZajgzCrGziLokDyGFwExc3TD/KYgIUBhmk7Xby lEfFlvxrJ4MHpkEE578yVl87U+LBT1TaqXg+QOIDI5jcDx51UrqQrN9GZ6MQzK+qnNs2 Q0VDaFgg0NFrm2SozwTQMBqruzSx6AXcjJRA4GvL5Y6D7vuG87Z5h9P+qhoWpd3cfqwt iW2eb4BlZCIU/quUZIrDoqzU1Asr5/5xtTfNM+nU0fThZOMBoG6kbkq3iPRIZtfp2H2B JZNg== 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 s10-v6si13338550pgs.189.2018.05.22.12.37.51; Tue, 22 May 2018 12:38:06 -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 S1752751AbeEVTg5 (ORCPT + 99 others); Tue, 22 May 2018 15:36:57 -0400 Received: from mga07.intel.com ([134.134.136.100]:16706 "EHLO mga07.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752537AbeEVTcE (ORCPT ); Tue, 22 May 2018 15:32:04 -0400 X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga005.jf.intel.com ([10.7.209.41]) by orsmga105.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 22 May 2018 12:32:00 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.49,430,1520924400"; d="scan'208";a="226406395" Received: from rchatre-s.jf.intel.com ([10.54.70.76]) by orsmga005.jf.intel.com with ESMTP; 22 May 2018 12:32:00 -0700 From: Reinette Chatre To: tglx@linutronix.de, fenghua.yu@intel.com, tony.luck@intel.com, vikas.shivappa@linux.intel.com Cc: gavin.hindman@intel.com, jithu.joseph@intel.com, dave.hansen@intel.com, mingo@redhat.com, hpa@zytor.com, x86@kernel.org, linux-kernel@vger.kernel.org, Reinette Chatre Subject: [PATCH V4 20/38] x86/intel_rdt: Protect against resource group changes during locking Date: Tue, 22 May 2018 04:29:08 -0700 Message-Id: <0116ee4001668934476c4f764d85df2e25389fa0.1526987654.git.reinette.chatre@intel.com> X-Mailer: git-send-email 2.13.6 In-Reply-To: References: In-Reply-To: References: Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org We intend to modify file permissions to make the "tasks", "cpus", and "cpus_list" not accessible to the user when cache pseudo-locking in progress. Even so, it is still possible for the user to force the file permissions (using chmod) to make them writeable. Similarly, directory permissions will be modified to prevent future monitor group creation but the user can override these restrictions also. Add additional checks to the files we intend to restrict to ensure that no modifications from user space are attempted while setting up a pseudo-locking or after a pseudo-locked region is set up. Signed-off-by: Reinette Chatre --- arch/x86/kernel/cpu/intel_rdt_ctrlmondata.c | 10 +++++++++ arch/x86/kernel/cpu/intel_rdt_rdtgroup.c | 32 +++++++++++++++++++++++++---- 2 files changed, 38 insertions(+), 4 deletions(-) diff --git a/arch/x86/kernel/cpu/intel_rdt_ctrlmondata.c b/arch/x86/kernel/cpu/intel_rdt_ctrlmondata.c index 0e6210a043f0..bc79396c5dad 100644 --- a/arch/x86/kernel/cpu/intel_rdt_ctrlmondata.c +++ b/arch/x86/kernel/cpu/intel_rdt_ctrlmondata.c @@ -283,6 +283,16 @@ ssize_t rdtgroup_schemata_write(struct kernfs_open_file *of, } rdt_last_cmd_clear(); + /* + * No changes to pseudo-locked region allowed. It has to be removed + * and re-created instead. + */ + if (rdtgrp->mode == RDT_MODE_PSEUDO_LOCKED) { + ret = -EINVAL; + rdt_last_cmd_puts("resource group is pseudo-locked\n"); + goto out; + } + for_each_alloc_enabled_rdt_resource(r) { list_for_each_entry(dom, &r->domains, list) dom->have_new_ctrl = false; diff --git a/arch/x86/kernel/cpu/intel_rdt_rdtgroup.c b/arch/x86/kernel/cpu/intel_rdt_rdtgroup.c index 3461fb25bb92..2df8bcabe085 100644 --- a/arch/x86/kernel/cpu/intel_rdt_rdtgroup.c +++ b/arch/x86/kernel/cpu/intel_rdt_rdtgroup.c @@ -449,6 +449,13 @@ static ssize_t rdtgroup_cpus_write(struct kernfs_open_file *of, goto unlock; } + if (rdtgrp->mode == RDT_MODE_PSEUDO_LOCKED || + rdtgrp->mode == RDT_MODE_PSEUDO_LOCKSETUP) { + ret = -EINVAL; + rdt_last_cmd_puts("pseudo-locking in progress\n"); + goto unlock; + } + if (is_cpu_list(of)) ret = cpulist_parse(buf, newmask); else @@ -651,13 +658,22 @@ static ssize_t rdtgroup_tasks_write(struct kernfs_open_file *of, if (kstrtoint(strstrip(buf), 0, &pid) || pid < 0) return -EINVAL; rdtgrp = rdtgroup_kn_lock_live(of->kn); + if (!rdtgrp) { + rdtgroup_kn_unlock(of->kn); + return -ENOENT; + } rdt_last_cmd_clear(); - if (rdtgrp) - ret = rdtgroup_move_task(pid, rdtgrp, of); - else - ret = -ENOENT; + if (rdtgrp->mode == RDT_MODE_PSEUDO_LOCKED || + rdtgrp->mode == RDT_MODE_PSEUDO_LOCKSETUP) { + ret = -EINVAL; + rdt_last_cmd_puts("pseudo-locking in progress\n"); + goto unlock; + } + + ret = rdtgroup_move_task(pid, rdtgrp, of); +unlock: rdtgroup_kn_unlock(of->kn); return ret ?: nbytes; @@ -2261,6 +2277,14 @@ static int mkdir_rdt_prepare(struct kernfs_node *parent_kn, goto out_unlock; } + if (rtype == RDTMON_GROUP && + (prdtgrp->mode == RDT_MODE_PSEUDO_LOCKSETUP || + prdtgrp->mode == RDT_MODE_PSEUDO_LOCKED)) { + ret = -EINVAL; + rdt_last_cmd_puts("pseudo-locking in progress\n"); + goto out_unlock; + } + /* allocate the rdtgroup. */ rdtgrp = kzalloc(sizeof(*rdtgrp), GFP_KERNEL); if (!rdtgrp) { -- 2.13.6