linux-kernel - Re: [RFC PATCH v3 00/16] Core scheduling v3

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:   Tue, 10 Sep 2019 10:27:17 -0400
From:   Julien Desfossez <jdesfossez@...italocean.com>
To:     Peter Zijlstra <peterz@...radead.org>
Cc:     Phil Auld <pauld@...hat.com>,
        Matthew Garrett <mjg59@...f.ucam.org>,
        Vineeth Remanan Pillai <vpillai@...italocean.com>,
        Nishanth Aravamudan <naravamudan@...italocean.com>,
        Tim Chen <tim.c.chen@...ux.intel.com>, mingo@...nel.org,
        tglx@...utronix.de, pjt@...gle.com, torvalds@...ux-foundation.org,
        linux-kernel@...r.kernel.org, subhra.mazumdar@...cle.com,
        fweisbec@...il.com, keescook@...omium.org, kerrnel@...gle.com,
        Aaron Lu <aaron.lwe@...il.com>,
        Aubrey Li <aubrey.intel@...il.com>,
        Valentin Schneider <valentin.schneider@....com>,
        Mel Gorman <mgorman@...hsingularity.net>,
        Pawan Gupta <pawan.kumar.gupta@...ux.intel.com>,
        Paolo Bonzini <pbonzini@...hat.com>
Subject: Re: [RFC PATCH v3 00/16] Core scheduling v3

On 29-Aug-2019 04:38:21 PM, Peter Zijlstra wrote:
> On Thu, Aug 29, 2019 at 10:30:51AM -0400, Phil Auld wrote:
> > I think, though, that you were basically agreeing with me that the current
> > core scheduler does not close the holes, or am I reading that wrong.
>
> Agreed; the missing bits for L1TF are ugly but doable (I've actually
> done them before, Tim has that _somewhere_), but I've not seen a
> 'workable' solution for MDS yet.

Following the discussion we had yesterday at LPC, after we have agreed
on a solution for fixing the current fairness issue, we will post the
v4. We will then work on prototyping the other synchronisation points
(syscalls, interrupts and VMEXIT) to evaluate the overhead in various
use-cases.

Depending on the use-case, we know the performance overhead maybe
heavier than just disabling SMT, but the benchmarks we have seen so far
indicate that there are valid cases for core scheduling. Core scheduling
will continue to be unused by default, but with it, we will have the
option to tune the system to be both secure and faster than disabling
SMT for those cases.

Thanks,

Julien

P.S: I think the branch that contains the VMEXIT handling is here
https://github.com/pdxChen/gang/commits/sched_1.23-base