linux-kernel - Re: [PATCH 0/5] Fix FIFO-99 abuse

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: <20190802093244.GF2332@hirez.programming.kicks-ass.net>
Date:   Fri, 2 Aug 2019 11:32:44 +0200
From:   Peter Zijlstra <peterz@...radead.org>
To:     Qais Yousef <qais.yousef@....com>
Cc:     mingo@...nel.org, linux-kernel@...r.kernel.org,
        Geert Uytterhoeven <geert@...ux-m68k.org>,
        Thomas Gleixner <tglx@...utronix.de>
Subject: Re: [PATCH 0/5] Fix FIFO-99 abuse

On Thu, Aug 01, 2019 at 02:17:07PM +0100, Qais Yousef wrote:
> On 08/01/19 13:13, Peter Zijlstra wrote:
> > I noticed a bunch of kthreads defaulted to FIFO-99, fix them.
> > 
> > The generic default is FIFO-50, the admin will have to configure the system
> > anyway.
> > 
> > For some the purpose is to be above OTHER and then FIFO-1 really is sufficient.
> 
> I was looking in this area too and was thinking of a way to consolidate the
> creation of RT/DL tasks in the kernel and the way we set the priority.
> 
> Does it make sense to create a new header for RT priorities for kthreads
> created in the kernel so that we can easily track and rationale about the
> relative priorities of in-kernel RT tasks?
> 
> When working in the FW world such a header helped a lot in understanding what
> runs at each priority level and how to reason about what priority level makes
> sense for a new item. It could be a nice single point of reference; even for
> admins.

Well, SCHED_FIFO is a broken scheduler model; that is, it is
fundamentally incapable of resource management, which is the one thing
an OS really should be doing.

This is of course the reason it is limited to privileged users only.

Worse still; it is fundamentally impossible to compose static priority
workloads. You cannot take two correctly working static prio workloads
and smash them together and still expect them to work.

For this reason 'all' FIFO tasks the kernel creates are basically at:

  MAX_RT_PRIO / 2

The administrator _MUST_ configure the system, the kernel simply doesn't
know enough information to make a sensible choice.

Now, Geert suggested so make make a define for that, but how about we do
something like:

/*
 * ${the above explanation}
 */
int kernel_setscheduler_fifo(struct task_struct *p)
{
	struct sched_param sp = { .sched_priority = MAX_RT_PRIO / 2 };
	return sched_setscheduler_nocheck(p, SCHED_FIFO, &sp);
}

And then take away sched_setscheduler*().