linux-kernel - Re: [PATCHv2 0/2] clone: Support passing tls argument via C rather than pt

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] [day] [month] [year] [list]

Date:	Tue, 12 May 2015 09:02:39 +0200
From:	Ingo Molnar <mingo@...nel.org>
To:	Josh Triplett <josh@...htriplett.org>
Cc:	Andy Lutomirski <luto@...capital.net>,
	Ingo Molnar <mingo@...hat.com>,
	"H. Peter Anvin" <hpa@...or.com>,
	Peter Zijlstra <peterz@...radead.org>,
	Thomas Gleixner <tglx@...utronix.de>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	linux-api@...r.kernel.org, linux-kernel@...r.kernel.org,
	x86@...nel.org
Subject: Re: [PATCHv2 0/2] clone: Support passing tls argument via C rather
 than pt_regs magic


* Josh Triplett <josh@...htriplett.org> wrote:

> clone has some of the quirkiest syscall handling in the kernel, with 
> a pile of special cases, historical curiosities, and 
> architecture-specific calling conventions.  In particular, clone 
> with CLONE_SETTLS accepts a parameter "tls" that the C entry point 
> completely ignores and some assembly entry points overwrite; 
> instead, the low-level arch-specific code pulls the tls parameter 
> out of the arch-specific register captured as part of pt_regs on 
> entry to the kernel.  That's a massive hack, and it makes the 
> arch-specific code only work when called via the specific existing 
> syscall entry points; because of this hack, any new clone-like 
> system call would have to accept an identical tls argument in 
> exactly the same arch-specific position, rather than providing a 
> unified system call entry point across architectures.
> 
> The first patch allows architectures to handle the tls argument via 
> normal C parameter passing, if they opt in by selecting 
> HAVE_COPY_THREAD_TLS.  The second patch makes 32-bit and 64-bit x86 
> opt into this.
> 
> These two patches came out of the clone4 series, which isn't ready 
> for this merge window, but these first two cleanup patches were 
> entirely uncontroversial and have acks.  I'd like to go ahead and 
> submit these two so that other architectures can begin building on 
> top of this and opting into HAVE_COPY_THREAD_TLS.  However, I'm also 
> happy to wait and send these through the next merge window (along 
> with v3 of clone4) if anyone would prefer that.
> 
> v2: Move co-author from signoffs to a note in the commit message, as
>     required by Ingo Molnar.
> 
> Josh Triplett (2):
>   clone: Support passing tls argument via C rather than pt_regs magic
>   x86: Opt into HAVE_COPY_THREAD_TLS, for both 32-bit and 64-bit
> 
>  arch/Kconfig                 |  7 ++++++
>  arch/x86/Kconfig             |  1 +
>  arch/x86/ia32/ia32entry.S    |  2 +-
>  arch/x86/kernel/process_32.c |  6 ++---
>  arch/x86/kernel/process_64.c |  8 +++----
>  include/linux/sched.h        | 14 +++++++++++
>  include/linux/syscalls.h     |  6 ++---
>  kernel/fork.c                | 55 +++++++++++++++++++++++++++++---------------
>  8 files changed, 69 insertions(+), 30 deletions(-)

So I have no objections if Linus doesn't see a cleaner/better 
approach.

Thanks,

	Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/