linux-kernel - Re: [PATCH] scheduler: introduce SCHED_RESET_ON

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]

Date:	Fri, 29 May 2009 12:39:25 +0200
From:	Lennart Poettering <mzxreary@...inter.de>
To:	Peter Zijlstra <peterz@...radead.org>
Cc:	linux-kernel@...r.kernel.org, Ingo Molnar <mingo@...e.hu>
Subject: Re: [PATCH] scheduler: introduce SCHED_RESET_ON_FORK scheduling
	policy flag, Second try

On Fri, 29.05.09 11:28, Peter Zijlstra (peterz@...radead.org) wrote:

> > This patch introduces a new flag SCHED_RESET_ON_FORK which can be passed
> > to the kernel via sched_setscheduler(), ORed in the policy parameter. If
> > set this will make sure that when the process forks a) the scheduling
> > priority is reset to DEFAULT_PRIO if it was higher and b) the scheduling
> > policy is reset to SCHED_NORMAL if it was either SCHED_FIFO or SCHED_RR.
> 
> Maybe SCHED_OTHER_ON_FORK, or SCHED_DEFAULT_ON_FORK?

Hmm, I think this would be misleading, since it does more than just
reset to SCHED_OTHER. It also resets the nice level.

> > +	if (current->sched_reset_on_fork &&
> > +			(p->policy == SCHED_FIFO || p->policy == SCHED_RR))
> > +		p->policy = SCHED_NORMAL;
> > +
> > +	if (current->sched_reset_on_fork &&
> > +			(current->normal_prio < DEFAULT_PRIO))
> > +		p->prio = DEFAULT_PRIO;
> > +	else
> > +		p->prio = current->normal_prio;
> 
> This bit hurt my brain, what's wrong with:
> 
> 	p->prio = current->normal_prio; /* don't leak boosted prio */
> 	if (current->sched_reset_on_fork) {
> 		p->policy = SCHED_NORMAL;
> 		p->prio = p->normal_prio = p->static_prio = DEFAULT_PRIO;
> 	}

This would do something very different. i.e. with this suggested code
of yours SCHED_IDLE/SCHED_BATCH would be upgraded to SCHED_OTHER on
fork and a process with a positive nice level would be upgraded to to
nice level 0. My original patch would only downgrade, never upgrade.

It is of course a question what makes more sense here: a logic that
makes sure that only "elevated" scheduling gets reset to normal
scheduling, or one that would reset both 'higher' and 'lower'
scheduling settings to normal.

Given that this is supposed to be a security feature it makes more
sense to me to only 'decrease' scheduling settings, not 'increase'
them. Dunno, what do you think?

Lennart

-- 
Lennart Poettering                        Red Hat, Inc.
lennart [at] poettering [dot] net
http://0pointer.net/lennart/           GnuPG 0x1A015CC4
--
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/