linux-kernel - Re: [RFC PATCH 0/3] Implement getcpu

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: <137700396.343696.1452559758752.JavaMail.zimbra@efficios.com>
Date:	Tue, 12 Jan 2016 00:49:18 +0000 (UTC)
From:	Mathieu Desnoyers <mathieu.desnoyers@...icios.com>
To:	Josh Triplett <josh@...htriplett.org>
Cc:	Shane M Seymour <shane.seymour@....com>,
	Thomas Gleixner <tglx@...utronix.de>,
	Paul Turner <pjt@...gle.com>, Andrew Hunter <ahh@...gle.com>,
	Peter Zijlstra <peterz@...radead.org>,
	linux-kernel@...r.kernel.org,
	linux-api <linux-api@...r.kernel.org>,
	Andy Lutomirski <luto@...capital.net>,
	Andi Kleen <andi@...stfloor.org>,
	Dave Watson <davejwatson@...com>, Chris Lameter <cl@...ux.com>,
	Ingo Molnar <mingo@...hat.com>, Ben Maurer <bmaurer@...com>,
	rostedt <rostedt@...dmis.org>,
	"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Russell King <linux@....linux.org.uk>,
	Catalin Marinas <catalin.marinas@....com>,
	Will Deacon <will.deacon@....com>,
	Michael Kerrisk <mtk.manpages@...il.com>
Subject: Re: [RFC PATCH 0/3] Implement getcpu_cache system call

----- On Jan 11, 2016, at 6:03 PM, Josh Triplett josh@...htriplett.org wrote:

> On Mon, Jan 11, 2016 at 10:38:28PM +0000, Seymour, Shane M wrote:
>> I have some concerns and suggestions for you about this.
>> 
>> What's to stop someone in user space from requesting an arbitrarily large number
>> of CPU # cache locations that the kernel needs to allocate memory to track and
>> each time the task migrates to a new CPU it needs to update them all? Could you
>> use it to dramatically slow down a system/task switching? Should there be a
>> ulimit type value or a sysctl setting to limit the number that you're allowed
>> to register per-task?
> 
> The documented behavior of the syscall allows only one location per
> thread, so the kernel can track that one and only address rather easily
> in the task_struct.  Allowing dynamic allocation definitely doesn't seem
> like a good idea.

The current implementation now allows more than one location per
thread. Which piece of documentation states that only one location
per thread is allowed ? This was indeed the case for the prior
implementations, but I moved to implementing a linked-list of
cpu_cache areas per thread to allow the getcpu_cache system call to
be used by more than a single shared object within a given program.

Without the linked list, as soon as more than one shared object try
to register their cache, the first one will prohibit all others from
doing so.

We could perhaps try to document that this system call should only
ever be used by *libc, and all libraries and applications should
then use the libc TLS cache variable, but it seems rather fragile,
and any app/lib could try to register its own cache.

Thoughts ?

Thanks,

Mathieu

-- 
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com