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;
Subject: Re: [PATCH v4 4/4] sched/core: Add permission checks for setting the
 latency_nice value
To:     Qais Yousef <qais.yousef@arm.com>, vincent.guittot@linaro.org,
        dietmar.eggemann@arm.com, chris.hyser@oracle.com,
        patrick.bellasi@matbug.net, valentin.schneider@arm.com,
        tim.c.chen@linux.intel.com
Cc:     linux-kernel@vger.kernel.org, peterz@infradead.org,
        mingo@redhat.com, David.Laight@ACULAB.COM, pjt@google.com,
        pavel@ucw.cz, tj@kernel.org, dhaval.giani@oracle.com,
        qperret@google.com
References: <20200224085918.16955-1-parth@linux.ibm.com>
 <20200224085918.16955-5-parth@linux.ibm.com>
 <20200224132905.32sdpbydnzypib47@e107158-lin.cambridge.arm.com>
From:   Parth Shah <parth@linux.ibm.com>
Date:   Tue, 25 Feb 2020 12:17:29 +0530
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101
 Thunderbird/60.4.0
MIME-Version: 1.0
In-Reply-To: <20200224132905.32sdpbydnzypib47@e107158-lin.cambridge.arm.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Message-Id: <9a4132f2-62cc-4132-1c6d-964ed679afc7@linux.ibm.com>
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk


On 2/24/20 6:59 PM, Qais Yousef wrote:
> On 02/24/20 14:29, Parth Shah wrote:
>> Since the latency_nice uses the similar infrastructure as NICE, use the
>> already existing CAP_SYS_NICE security checks for the latency_nice. This
>> should return -EPERM for the non-root user when trying to set the task
>> latency_nice value to any lower than the current value.
>>
>> Signed-off-by: Parth Shah <parth@linux.ibm.com>
> 
> I'm not against this, so I'm okay if it goes in as is.
> 
> But IMO the definition of this flag is system dependent and I think it's
> prudent to keep it an admin only configuration.
> 
> It'd be hard to predict how normal application could use and depend on this
> feature in the future, which could tie our hand in terms of extending it.
> 

I am fine with this going in too. But just to lie down the fact on single
page and starting the discussion, here are the pros and cons for including
this permission checks:

Pros:
=====
- Having this permission checks will allow only root users to promote the
task, meaning lowering the latency_nice of the task. This is required in
case when the admin has increased the latency_nice value of a task and
non-root user can not lower it.
- In absence of this check, the non-root user can decrease the latency_nice
value against the admin configured value.

Cons:
=====
- This permission check prevents the non-root user to lower the value. This
is a problem when the user itself has increased the latency_nice value in
the past but fails to lower it again.
- After task fork, non-root user cannot lower the inherited child task's
latency_nice value, which might be a problem in the future for extending
this latency_nice ideas for different optimizations.


> I can't argue hard about this though. But I do feel going further and have
> a sched_feature() for each optimization that uses this flag could be necessary
> too.

I agree to your point.


Thanks,
Parth

> 
> Thanks
> 
> --
> Qais Yousef
> 
>> ---
>>  kernel/sched/core.c | 4 ++++
>>  1 file changed, 4 insertions(+)
>>
>> diff --git a/kernel/sched/core.c b/kernel/sched/core.c
>> index e1dc536d4ca3..f883e1d3cd10 100644
>> --- a/kernel/sched/core.c
>> +++ b/kernel/sched/core.c
>> @@ -4887,6 +4887,10 @@ static int __sched_setscheduler(struct task_struct *p,
>>  			return -EINVAL;
>>  		if (attr->sched_latency_nice < MIN_LATENCY_NICE)
>>  			return -EINVAL;
>> +		/* Use the same security checks as NICE */
>> +		if (attr->sched_latency_nice < p->latency_nice &&
>> +		    !can_nice(p, attr->sched_latency_nice))
>> +			return -EPERM;
>>  	}
>>  
>>  	if (pi)
>> -- 
>> 2.17.2
>>