linux-kernel - Re: [update] Re: new execve/kernel

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: <20121027033222.GT2616@ZenIV.linux.org.uk>
Date:	Sat, 27 Oct 2012 04:32:22 +0100
From:	Al Viro <viro@...IV.linux.org.uk>
To:	linux-kernel@...r.kernel.org
Cc:	linux-arch@...r.kernel.org,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Catalin Marinas <catalin.marinas@....com>,
	Haavard Skinnemoen <hskinnemoen@...il.com>,
	Mike Frysinger <vapier@...too.org>,
	Jesper Nilsson <jesper.nilsson@...s.com>,
	David Howells <dhowells@...hat.com>,
	Tony Luck <tony.luck@...el.com>,
	Benjamin Herrenschmidt <benh@...nel.crashing.org>,
	Hirokazu Takata <takata@...ux-m32r.org>,
	Geert Uytterhoeven <geert@...ux-m68k.org>,
	Michal Simek <monstr@...str.eu>,
	Jonas Bonn <jonas@...thpole.se>,
	"James E.J. Bottomley" <jejb@...isc-linux.org>,
	Richard Kuo <rkuo@...eaurora.org>,
	Martin Schwidefsky <schwidefsky@...ibm.com>,
	Lennox Wu <lennox.wu@...il.com>,
	"David S. Miller" <davem@...emloft.net>,
	Paul Mundt <lethal@...ux-sh.org>,
	Chris Zankel <chris@...kel.net>,
	Chris Metcalf <cmetcalf@...era.com>,
	Yoshinori Sato <ysato@...rs.sourceforge.jp>,
	Guan Xuetao <gxt@...c.pku.edu.cn>
Subject: Re: [update] Re: new execve/kernel_thread design

On Fri, Oct 26, 2012 at 07:31:07PM +0100, Al Viro wrote:
> 	The situation got much better by now.  More than a half of
> architectures are done - alpha arm arm64 c6x hexagon ia64 m68k mips openrisc
> parisc sparc tile um unicore32 and x86.
> 
> 	Two more avait ACKs from maintainers - powerpc and s390.  Should work,
> AFAICS.
> 
> 	xtensa - Max was going to repost updated patches; waiting for that
> to happen, but essentially it's done and tested.
> 
> 	microblaze - Michal was debugging kernel_execve side of it the last
> time I've heard from him...
> 
> 	frv, mn10300 - dhowells was going to test those
> 
> 	sh - Paul Mundt was going to test and send fixes
> 
> 	avr32, blackfin, cris, h8300, m32r, score - no signs of life from
> maintainers.  Folks, please show up and at least test the damn patchsets.
> Hell knows, they might even work - unicore32 one did, modulo trivial typo,
> to my deep surprise...

BTW, there's a tangentially related issue: several architectures have
very odd clone(2).  Namely, blackfin, h8300, no-MMU microblaze and sh64 (==sh5)
silently ignore child_tidptr and parent_tidptr arguments.  I.e. treat them
as NULL - or as if CLONE_PARENT_SETTID/CLONE_CHILD_SETTID/CLONE_CHILD_CLEARTID
were never set.  With the patchset in the local part of queue it would be
trivial to switch to normal semantics; strictly speaking, it's an ABI change.
Somebody doing
	n = 0x69696969;
	if (clone(CLONE_PARENT_SETTID, 0, &n) > 0) {
		if (n != 0x69696969) {
			printf("oh, shit, we are not on blackfin\n");
			exit(-1);
		}
	}
would run into a user-visible behaviour change, but IMO that's in the realm
of testing for known architecture-dependent bugs and finding them fixed...

Opinions, vetoes?  Should we preserve the current behaviour in this case?
I would obviously prefer to just go ahead and fix the sucker - the odds of
any actual software depending on that behaviour are pretty much nil.
Linus, does that cross the boundary between bug fix and ABI breakage?

Another curious thing happens on blackfin; there we subtract 12 from usp
when it's non-zero (zero == inherit the parent's usp, as always).  No idea
why is that done; this one definitely has to be preserved, so I'm just
wondering about the reasons behind that oddity...  Mike?
--
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/