Received: by 2002:ac0:a5b6:0:0:0:0:0 with SMTP id m51-v6csp3806454imm; Tue, 29 May 2018 14:09:52 -0700 (PDT) X-Google-Smtp-Source: ADUXVKKf2gSGBbRUWL5NLSNvWxOYr89e6KGNKOtdeTjMOCS9N5wYNTsx8YWNBtauRFXmGOElHQch X-Received: by 2002:a17:902:4603:: with SMTP id o3-v6mr42705pld.49.1527628192568; Tue, 29 May 2018 14:09:52 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1527628192; cv=none; d=google.com; s=arc-20160816; b=a3QegnHPN9mFxnYjxTBGeGdJVscUVkqWSfvzKwIjp6IeYEwF0IEeUl38n5uoqRjPtm 7VwmNYL5sk9Ern5eejqhKgO6ZwzOqf69MthLMPtCOS9CVv9EGTBqp6l7ML9cycbplC+6 E4OGoAXFYK6puAMnRDvpc5pRHnHBc+/AJ3GB0Lc8taXay9yeGvJ+B9d5krqCXrzR6zMk 3O1/c7vzsJOrmolWbPXVWIui3WCRoO2u1/Phi7ZhojivfUtFptJSDdOOiu3RZLM4N8Tv tHb3bLL8adsfN2XoeMQoJzE+hDCYWQ3qOzien/3fuBPxvfdeV3xjraYtvMh4CMNrM2qT UAeQ== 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=v2VjbtI5eImxCuGPI3AahgBL/1siwmaeCtRLWLIqm7E=; b=pJQNt2FOBrfHCGoSafp9fUhX0Fmw0uNL8udv9O2Fh0WMPiMAMWcqwz+S+zMb5ND64q XzoF54iqZWpimOq/0+yhLVRq6z3PCjWePJC81pgZe7tvij3KXhDC/Yowkwqnk5CPWEB5 HK8c/bNDDEfbcqdqRYvq9H7kM105TwuCX91/2QJQu3BPEJ31uXCUEUvE748xUwAbKsUR wkJI2Wro/LqirtBZfo1L3G9sh2yK/85TppbO28kjDXHMgpyL77abu6TmyhThXAw4gwUF mKvoe6I07UADcuJcws0dUtSE0gg4I+mG54PKjKTlpptvAxApnBeby9Xq1eVaDHxzu6ei hk7Q== 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 e200-v6si10910874pfh.64.2018.05.29.14.09.38; Tue, 29 May 2018 14:09:52 -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 S937303AbeE2VIG (ORCPT + 99 others); Tue, 29 May 2018 17:08:06 -0400 Received: from mga14.intel.com ([192.55.52.115]:46449 "EHLO mga14.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S937064AbeE2VA5 (ORCPT ); Tue, 29 May 2018 17:00:57 -0400 X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga001.jf.intel.com ([10.7.209.18]) by fmsmga103.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 29 May 2018 14:00:55 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.49,457,1520924400"; d="scan'208";a="60127727" Received: from rchatre-s.jf.intel.com ([10.54.70.76]) by orsmga001.jf.intel.com with ESMTP; 29 May 2018 14:00:54 -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 V5 20/38] x86/intel_rdt: Protect against resource group changes during locking Date: Tue, 29 May 2018 05:57:45 -0700 Message-Id: <14b7a6e8ab2991130a98381d7075bb254e761050.1527593971.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 0337197dcde3..178990850b03 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