linux-kernel - Re: [PATCH v3 0/3] Introduce per-task latency

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: <20200221092956.jpsfps2dgmhiu5vg@e107158-lin.cambridge.arm.com>
Date:   Fri, 21 Feb 2020 09:29:57 +0000
From:   Qais Yousef <qais.yousef@....com>
To:     chris hyser <chris.hyser@...cle.com>
Cc:     Parth Shah <parth@...ux.ibm.com>, vincent.guittot@...aro.org,
        patrick.bellasi@...bug.net, valentin.schneider@....com,
        dhaval.giani@...cle.com, dietmar.eggemann@....com,
        linux-kernel@...r.kernel.org, peterz@...radead.org,
        mingo@...hat.com, pavel@....cz, qperret@...rret.net,
        David.Laight@...LAB.COM, pjt@...gle.com, tj@...nel.org
Subject: Re: [PATCH v3 0/3] Introduce per-task latency_nice for scheduler
 hints

On 02/20/20 11:34, chris hyser wrote:
> > > Whether called a hint or not, it is a trade-off to reduce latency of select
> > > tasks at the expense of the throughput of the other tasks in the the system.
> > 
> > Does it actually affect the throughput of the other tasks? I thought this will
> > allow the scheduler to reduce latencies, for instance, when selecting which cpu
> > it should land on. I can't see how this could hurt other tasks.
> 
> This is why it is hard to argue about pure abstractions. The primary idea
> mentioned so far for how these latencies are reduced is by short cutting the
> brute-force search for something idle. If you don't find an idle cpu because
> you didn't spend the time to look, then you pre-empted a task, possibly with
> a large nice warm cache footprint that was cranking away on throughput. It
> is ultimately going to be the usual latency vs throughput trade off. If
> latency reduction were "free" we wouldn't need a per task attribute. We
> would just do the reduction for all tasks, everywhere, all the time.

This could still happen without the latency nice bias. I'm not sure if this
falls under DoS; maybe if you end up spawning a lot of task with high latency
nice value, then you might end up cramming a lot of tasks on a small subset of
CPUs. But then, shouldn't the logic that uses latency_nice try to handle this
case anyway since it could be legit?

Not sure if this can be used by someone to trigger timing based attacks on
another process.

I can't fully see the whole security implications, but regardless. I do agree
it is prudent to not allow tasks to set their own latency_nice. Mainly because
the meaning of this flag will be system dependent and I think Admins are the
better ones to decide how to use this flag for the system they're running on.
I don't think application writers should be able to tweak their tasks
latency_nice value. Not if they can't get the right privilege at least.

> 
> > 
> > Can you expand on the scenario you have in mind please?
> 
> Hopefully, the above helps. It was my original plan to introduce this with a
> data laden RFC on the topic, but I felt the need to respond to Parth
> immediately. I'm not currently pushing any particular change.

Thanks!

--
Qais Yousef