linux-kernel - Re: [PATCH v10 05/12] task_isolation: support CONFIG_TASK_ISOLATION

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:	Thu, 3 Mar 2016 14:40:14 -0500
From:	Chris Metcalf <cmetcalf@...lanox.com>
To:	Andi Kleen <andi@...stfloor.org>
CC:	Gilad Ben Yossef <giladb@...hip.com>,
	Steven Rostedt <rostedt@...dmis.org>,
	Ingo Molnar <mingo@...nel.org>,
	Peter Zijlstra <peterz@...radead.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	"Rik van Riel" <riel@...hat.com>, Tejun Heo <tj@...nel.org>,
	Frederic Weisbecker <fweisbec@...il.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>,
	Christoph Lameter <cl@...ux.com>,
	Viresh Kumar <viresh.kumar@...aro.org>,
	Catalin Marinas <catalin.marinas@....com>,
	Will Deacon <will.deacon@....com>,
	Andy Lutomirski <luto@...capital.net>,
	<linux-doc@...r.kernel.org>, <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v10 05/12] task_isolation: support
 CONFIG_TASK_ISOLATION_ALL

On 03/03/2016 01:34 PM, Andi Kleen wrote:
> Chris Metcalf <cmetcalf@...hip.com> writes:
>>   
>> +config TASK_ISOLATION_ALL
>> +	bool "Provide task isolation on all CPUs by default (except CPU 0)"
>> +	depends on TASK_ISOLATION
>> +	help
>> +	 If the user doesn't pass the task_isolation boot option to
>> +	 define the range of task isolation CPUs, consider that all
>> +	 CPUs in the system are task isolation by default.
>> +	 Note the boot CPU will still be kept outside the range to
>> +	 handle timekeeping duty, etc.
> That seems like a very dangerous Kconfig option.
> "CONFIG_BREAK_EVERYTHING"
> If someone sets that by default they will have a lot of trouble.
>
> I wouldn't add that, make it a run time option only.

So you were thinking, allow a special boot syntax "task_isolation=all",
which puts all the cores into task isolation mode except the boot core?

My original argument was that it was so parallel to the existing
CONFIG_NO_HZ_FULL_ALL option that it just made sense to do it,
and some testers complained about having to specify the precise
cpu range, so this seemed like an easy fix.

The commit comment for NO_HZ_FULL_ALL (f98823ac758ba) reads:

     nohz: New option to default all CPUs in full dynticks range
    
     Provide a new kernel config that defaults all CPUs to be part
     of the full dynticks range, except the boot one for timekeeping.
    
     This default setting is overriden by the nohz_full= boot option
     if passed by the user.
    
     This is helpful for those who don't need a finegrained range
     of full dynticks CPU and also for automated testing.

The same arguments would seem to apply to TASK_ISOLATION_ALL;
note that applications don't actually go into task isolation mode
without issuing the appropriate prctl(), so it shouldn't be too
dangerous if users enable it by mistake.  There will be some
extra checks at kernel entry and exit, that's all.

So on balance it still seems like a reasonable choice.  Thoughts?

-- 
Chris Metcalf, Mellanox Technologies
http://www.mellanox.com