Received: by 2002:ac0:a581:0:0:0:0:0 with SMTP id m1-v6csp1373321imm; Fri, 22 Jun 2018 15:44:43 -0700 (PDT) X-Google-Smtp-Source: ADUXVKJAqEOuKrpao5onhalTXJHycamw4lzEfZqVTGHdK7OStsQWTRYXJC8Re0tRwWgc3cNBncbP X-Received: by 2002:a62:10c2:: with SMTP id 63-v6mr3253523pfq.229.1529707483245; Fri, 22 Jun 2018 15:44:43 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1529707483; cv=none; d=google.com; s=arc-20160816; b=u2onM7khGxkdtJ1WUw3q1waM2jxzSjRWXSpIgJZJgILFXOX3nvTqCXasMyCaIkxLQE jOzGOzJ5Hh2xCyQl+XpMLyg24//zbUnevQoz6HzGGiipyQO39f+JO8gWq/SfIxOAc9NW bN5rfcq9IPcE6qYpJ33qyhwsmw5Nyh797KaBGCFtIJOpl8C6TDT3n2OpmVL+0a8LHTq9 3mbfZPDRcQYxcLhUgubvFHJqYZocA0vp4J1+anPsb8aBJaZEltRkCfLAbFOFK17AzL8I hJ8hNQJVc1CWN8Y3ZhYETAFR1daPyAJ2aV8OBgVkirLtqawEhUoRfR8gZ6hM6wHXbT4P uBCA== 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=wj/rvcJgkT2mnJt/QO6Qw2PoFJCDSvDuNUkPsgUS3mA=; b=czze9hRiE52WpRez6bi7o+LBH7znKQSZjnAC6Jvq6bcK+n3p7zcIDMkYn1nqOlMjp1 rIpUKA+PCvG6QHBC/BNxySbMHMuO7nF8GSmpdyUlyWwEVHYL7FUfbU26U3JpsJiKT/IH 236NQn1oE78FKtMRhOS5DxIz3cF/HQ+9EczOrPXXSuCpJcdomVf1iW9vTeKqt1LoZyWB /DO8gDj/qBCrsgnKxu/kuPhsVyBxsfklfBwbg468kbiyaoBkgq9wz0SWWB340nfo8i2a TEu75iNFv9s6tGG0qyTlXvBulfm4D/sI3GyrKFxRTKyx+9NmBfH/oCPqk2CJMrpEtfsn K3+Q== 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 p7-v6si6905055pga.25.2018.06.22.15.44.29; Fri, 22 Jun 2018 15:44:43 -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 S934044AbeFVWnB (ORCPT + 99 others); Fri, 22 Jun 2018 18:43:01 -0400 Received: from mga17.intel.com ([192.55.52.151]:52514 "EHLO mga17.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933839AbeFVWmt (ORCPT ); Fri, 22 Jun 2018 18:42:49 -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 fmsmga107.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 22 Jun 2018 15:42:48 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.51,259,1526367600"; d="scan'208";a="234843412" Received: from rchatre-s.jf.intel.com ([10.54.70.76]) by orsmga005.jf.intel.com with ESMTP; 22 Jun 2018 15:42:47 -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 V7 21/41] x86/intel_rdt: Protect against resource group changes during locking Date: Fri, 22 Jun 2018 15:42:12 -0700 Message-Id: <0c5cb006e81ead0b8bfff2df530c5d3017fd31d1.1529706536.git.reinette.chatre@intel.com> X-Mailer: git-send-email 2.17.0 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 Signed-off-by: Thomas Gleixner Cc: fenghua.yu@intel.com Cc: tony.luck@intel.com Cc: vikas.shivappa@linux.intel.com Cc: gavin.hindman@intel.com Cc: jithu.joseph@intel.com Cc: dave.hansen@intel.com Cc: hpa@zytor.com Link: https://lkml.kernel.org/r/14b7a6e8ab2991130a98381d7075bb254e761050.1527593971.git.reinette.chatre@intel.com --- 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 c17d5399b9f1..717f19035309 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; @@ -2324,6 +2340,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.17.0