linux-kernel - Re: [PATCH 10/16] sched: add resource limits for -deadline tasks.

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <4F96C52C.7030606@gmail.com>
Date:	Tue, 24 Apr 2012 17:22:20 +0200
From:	Juri Lelli <juri.lelli@...il.com>
To:	Peter Zijlstra <peterz@...radead.org>
CC:	tglx@...utronix.de, mingo@...hat.com, rostedt@...dmis.org,
	cfriesen@...tel.com, oleg@...hat.com, fweisbec@...il.com,
	darren@...art.com, johan.eker@...csson.com, p.faure@...tech.ch,
	linux-kernel@...r.kernel.org, claudio@...dence.eu.com,
	michael@...rulasolutions.com, fchecconi@...il.com,
	tommaso.cucinotta@...up.it, nicola.manica@...i.unitn.it,
	luca.abeni@...tn.it, dhaval.giani@...il.com, hgu1972@...il.com,
	paulmck@...ux.vnet.ibm.com, raistlin@...ux.it,
	insop.song@...csson.com, liming.wang@...driver.com
Subject: Re: [PATCH 10/16] sched: add resource limits for -deadline tasks.

On 04/24/2012 05:07 PM, Peter Zijlstra wrote:
> On Fri, 2012-04-06 at 09:14 +0200, Juri Lelli wrote:
>> From: Dario Faggioli<raistlin@...ux.it>
>>
>> Add resource limits for non-root tasks in using the SCHED_DEADLINE
>> policy, very similarly to what already exists for RT policies.
>>
>> In fact, this patch:
>>   - adds the resource limit RLIMIT_DLDLINE, which is the minimum value
>>     a user task can use as its own deadline;
>>   - adds the resource limit RLIMIT_DLRTIME, which is the maximum value
>>     a user task can use as it own runtime.
>>
>> Notice that to exploit these, a modified version of the ulimit
>> utility and a modified resource.h header file are needed. They
>> both will be available on the website of the project.
>>
>> Signed-off-by: Dario Faggioli<raistlin@...ux.it>
>> Signed-off-by: Juri Lelli<juri.lelli@...il.com>
>
> I'm not sure this is the right way to go.. those existing things aren't
> entirely as useful/sane as one might hope either.
>
> The DLDLINE minimum is ok I guess, the DLRTIME one doesn't really do
> anything, by spawning multiple tasks one can still saturate the cpu and
> thus we have no effective control for unpriv users.
>
> Ideally DLRTIME would be a utilization cap per user and tracked in
> user_struct such that we can enforce a max utilization per user.
>
> This also needs a global (and possibly per-cgroup) user limit too to cap
> the total utilization of all users (excluding root) so that multiple
> users cannot combine their efforts in order to bring down the machine.
>
> In light of these latter controls the per-user control might be
> considered optional, furthermore I don't particularly like the rlimit
> infrastructure but I guess its the best we have for per-user like things
> if indeed we want to go there.

Ok, but considering what you said regarding setscheduler security problems:

On 04/24/2012 11:00 AM, Peter Zijlstra wrote:
> On Tue, 2012-04-24 at 09:21 +0200, Juri Lelli wrote:
>> >  Well, depends on how much effort will this turn to require. I personally
>> >  would prefer to be able to come out with a new release ASAP. Just to
>> >  continue the discussion with the most of the comments addressed and a
>> >  more updated code (I also have a mainline version of the patchset
>> >  quite ready).
> Right, one thing we can initially do is require root for using
> SCHED_DEADLINE and then when later work closes all the holes and we've
> added user bandwidth controls we can allow everybody in.

Are you suggesting to drop/postpone this to some later time?

Thanks,

- Juri
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/