linux-kernel - Re: [PATCHv2 1/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] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 12 May 2015 14:22:50 -0700
From:	Andrew Morton <akpm@...ux-foundation.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 1/2] clone: Support passing tls argument via C rather
 than pt_regs magic

On Mon, 11 May 2015 12:29:19 -0700 Josh Triplett <josh@...htriplett.org> wrote:

> Introduce a new CONFIG_HAVE_COPY_THREAD_TLS for architectures to opt
> into, and a new copy_thread_tls that accepts the tls parameter as an
> additional unsigned long (syscall-argument-sized) argument.
> Change sys_clone's tls argument to an unsigned long (which does
> not change the ABI), and pass that down to copy_thread_tls.
> 
> Architectures that don't opt into copy_thread_tls will continue to
> ignore the C argument to sys_clone in favor of the pt_regs captured at
> kernel entry, and thus will be unable to introduce new versions of the
> clone syscall.

What happens quite frequently is that we do something for x86 with the
expectation that other architectures will follow along, but this
doesn't happen.  The arch maintainers simply didn't know about it or
nobody nags them.  Nothing happens and inconsistencies hang around for
years.  eg, http://lkml.iu.edu/hypermail/linux/kernel/1504.2/04993.html

I'm thinking we should find a way to do this better.  One way might be
to maintain a Documentation/arch-todo which identifies each item, has a
little list of what-to-do instructions and perhaps a list of the
not-yet-done architectures.  Basically a way for everyone to
communicate at the arch maintainers.
--
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/