Received: by 2002:ac0:a581:0:0:0:0:0 with SMTP id m1-v6csp1374712imm; Fri, 22 Jun 2018 15:46:55 -0700 (PDT) X-Google-Smtp-Source: ADUXVKKsQkOuZjSmUbJCrRsBIC60JzbhmHn6ZBTu7m6Se+RS5ab2tqERVykz63M6rjrNKnvUpD/+ X-Received: by 2002:a65:6397:: with SMTP id h23-v6mr2944150pgv.380.1529707615032; Fri, 22 Jun 2018 15:46:55 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1529707615; cv=none; d=google.com; s=arc-20160816; b=kE41I+FApZOYP970u9lUPGIrA6YgMLEqBYqRWuKsD2jXg2LlitCI88wopWBA/94bpn 5/DgaTUEZVJaX5MfTOH5qt8MPqLZvPxxqt1z6vxOxAf4ZOEueBcDX2xwlbzin4iaI/hI zHVz9GAWTOUkyaIEcYYrJP6UiPguho2+i304N0PO2ttUF+t8epkvzdZmXsFNjnW8cUVT TSamUX9DriE5BB5qdr5FqKB7F/BolUJofdHVPi3ypRMeZD4NtGdWWANTatP6k7lnEBfQ KOXZuf7Mngv2wMrOf/j02KFZhJQUnIsqChFMmDV/uvEcdDOlh3pI8pA8PHdd78IWzP98 v0LQ== 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=MNmLOq80AgcrBoasyu1/ocUstVo/AsY8rmWtITFvMCY=; b=oXuqWEG/BdotmPptDaSlslEfYTRyT0lG/xEbxuQUTg2RtVJ0DnDivZRuA2gj4xhlEO p4X58UvCLSZYQ62g8J2XHXXKLy0hB086hOQWLqJ0jQ2YHi40qkegwqZWywTqlKkB7Ib6 QFayV/YFCLleS6IXXMyArTaJ3yoNzb7JrIs4RgKL7+Iu6AW9C/7lS4+dconN25W9uIvf rRCnwY92o5cT1Wf7HuQlw/IWJ8jeLvED0FazeJvCMOTDdGaOC1KDs+9uufNUhcbJjVH0 DbQH1rGh1P2GM6Zpu/iBOMSSVeiSIEzg6Qbhy9NrDKiM9FVkNFk7XCNUiGchG1ko3/d2 jp+g== 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 u190-v6si8704654pfb.325.2018.06.22.15.46.40; Fri, 22 Jun 2018 15:46:55 -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 S933955AbeFVWmz (ORCPT + 99 others); Fri, 22 Jun 2018 18:42:55 -0400 Received: from mga02.intel.com ([134.134.136.20]:22310 "EHLO mga02.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933639AbeFVWmt (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 orsmga101.jf.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="234843402" 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 18/41] x86/intel_rdt: Respect read and write access Date: Fri, 22 Jun 2018 15:42:09 -0700 Message-Id: <26f4fc25f110bfc07c2d2c8b2c4ee904922fedf7.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 By default, if the opener has CAP_DAC_OVERRIDE, a kernfs file can be opened regardless of RW permissions. Writing to a kernfs file will thus succeed even if permissions are 0000. It's required to restrict the actions that can be performed on a resource group from userspace based on the mode of the resource group. This restriction will be done through a modification of the file permissions. That is, for example, if a resource group is locked then the user cannot add tasks to the resource group. For this restriction through file permissions to work it has to be ensured that the permissions are always respected. To do so the resctrl filesystem is created with the KERNFS_ROOT_EXTRA_OPEN_PERM_CHECK flag that will result in open(2) failing with -EACCESS regardless of CAP_DAC_OVERRIDE if the permission does not have the respective read or write access. 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/c8b54235b16f40b74fded417f5b6151afe8f27b1.1527593970.git.reinette.chatre@intel.com --- arch/x86/kernel/cpu/intel_rdt_rdtgroup.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/arch/x86/kernel/cpu/intel_rdt_rdtgroup.c b/arch/x86/kernel/cpu/intel_rdt_rdtgroup.c index 336bc686a962..352475a6cf43 100644 --- a/arch/x86/kernel/cpu/intel_rdt_rdtgroup.c +++ b/arch/x86/kernel/cpu/intel_rdt_rdtgroup.c @@ -2554,7 +2554,8 @@ static int __init rdtgroup_setup_root(void) int ret; rdt_root = kernfs_create_root(&rdtgroup_kf_syscall_ops, - KERNFS_ROOT_CREATE_DEACTIVATED, + KERNFS_ROOT_CREATE_DEACTIVATED | + KERNFS_ROOT_EXTRA_OPEN_PERM_CHECK, &rdtgroup_default); if (IS_ERR(rdt_root)) return PTR_ERR(rdt_root); -- 2.17.0