linux-kernel - Re: [RFC 00/60] Coscheduling for Linux

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: <3fbb5a02-1fc6-eaaf-b8b5-be8d24133747@amazon.de>
Date:   Sat, 27 Oct 2018 02:07:12 +0200
From:   Jan H. Schönherr <jschoenh@...zon.de>
To:     Subhra Mazumdar <subhra.mazumdar@...cle.com>
Cc:     Ingo Molnar <mingo@...hat.com>,
        Peter Zijlstra <peterz@...radead.org>,
        linux-kernel@...r.kernel.org
Subject: Re: [RFC 00/60] Coscheduling for Linux

On 27/10/2018 01.05, Subhra Mazumdar wrote:
> 
> 
>> D) What can I *not* do with this?
>> ---------------------------------
>>
>> Besides the missing load-balancing within coscheduled task-groups, this
>> implementation has the following properties, which might be considered
>> short-comings.
>>
>> This particular implementation focuses on SCHED_OTHER tasks managed by CFS
>> and allows coscheduling them. Interrupts as well as tasks in higher
>> scheduling classes are currently out-of-scope: they are assumed to be
>> negligible interruptions as far as coscheduling is concerned and they do
>> *not* cause a preemption of a whole group. This implementation could be
>> extended to cover higher scheduling classes. Interrupts, however, are an
>> orthogonal issue.
>>
>> The collective context switch from one coscheduled set of tasks to another
>> -- while fast -- is not atomic. If a use-case needs the absolute guarantee
>> that all tasks of the previous set have stopped executing before any task
>> of the next set starts executing, an additional hand-shake/barrier needs to
>> be added.
>>
> The leader doesn't kick the other cpus _immediately_ to switch to a
> different cosched group. 

It does. (Or at least, it should, in case you found evidence that it does not.)

Specifically, the logic to not preempt the currently running task before
some minimum time has passed, is without effect for a collective context
switch.

> So threads from previous cosched group will keep
> running in other HTs till their sched_slice is over (in worst case). This
> can still keep the window of L1TF vulnerability open?

No. Per the above, the window due to the collective context switch should
not be as long as "the remaining time slice" but more towards the IPI
delay. During this window, tasks of different coscheduling groups may
execute simultaneously.

In addition (as mentioned in the quoted text above), there more cases where
a task of a coscheduled group on one SMT sibling may execute simultaneously
with some other code not from the same coscheduled group: tasks in
scheduling classes higher than CFS, and interrupts -- as both of them
operate outside the scope of the coscheduler.

Regards
Jan