linux-kernel - Re: [RFC PATCH] sched/fair: Optionally restrict SMT scheduling ("restrict

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <1517495872.23787.20.camel@gmx.de>
Date:   Thu, 01 Feb 2018 15:37:52 +0100
From:   Mike Galbraith <efault@....de>
To:     Sergio Lopez <slp@...rega.org>, linux-kernel@...r.kernel.org
Cc:     mingo@...hat.com, peterz@...radead.org
Subject: Re: [RFC PATCH] sched/fair: Optionally restrict SMT scheduling
 ("restrict_smt")

On Thu, 2018-02-01 at 13:37 +0100, Sergio Lopez wrote:
> "restrict_smt" is an optional security feature that, when enabled,
> automatically adjusts the cpus_allowed mask of user tasks with CFS
> policies, forcing them to run on the first SMT thread of each core.
> 
> This security feature prevents user tasks from running on SMT sibling
> threads, difficulting the abuse of shared physical resources to
> construct covert side-channels or spying on other tasks. "restrict_smt"
> also helps in the mitigation of some HT-based Spectre v2 attack
> scenarios.
> 
> Users with CAP_SYS_NICE are still able to schedule tasks on secondary
> SMT threads by exclusively pinning to the latter, so "restrict_smt"
> won't interfere with resource planification strategies depending on
> that, like vCPU pinning for KVM Guests.
> 
> Compared against disabling SMT at a hardware level, "restrict_smt"
> presents the following advantages:
>  - Secondary SMT threads can still be used by kthreads, or by user
> tasks exclusively pinned to them.
> 
> Compared against "isolcpus", "restrict_smt" presents the following
> advantages:
>  - Doesn't require prior knowledge of the CPU topology, making it more
> friendly to both end users and automation tools.
>  - Load balancing is still active for tasks pinned to multiple secondary
> SMT threads.

This says that everybody and everything in the box is way smarter than
the admin.

	-Mike