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: <alpine.LFD.2.00.1002010741560.4206@localhost.localdomain>
Date:	Mon, 1 Feb 2010 07:57:34 -0800 (PST)
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Michal Simek <michal.simek@...alogix.com>
cc:	LKML <linux-kernel@...r.kernel.org>, hpa@...or.com,
	John Williams <john.williams@...alogix.com>
Subject: Re: Split 'flush_old_exec' into two functions -
 221af7f87b97431e3ee21ce4b0e77d5411cf1549



On Mon, 1 Feb 2010, Michal Simek wrote:
>
> Hi Peter and Linus,
> 
> commit 221af7f87b97431e3ee21ce4b0e77d5411cf1549 breaks anything on Microblaze.

Gaah. My original version of that patch very much tried to make it a no-op 
semantically, but then Peter made some preparatory changes for the next 
patch, so it actually changes semantics a bit. I was expecting that to be 
benign, but clearly there are issues.

> None reported any problem that's why I think that is Microblaze related.

Well, our previous handling of the critical stage of 'execve()' when we 
actually switch from the old process to the new was _so_ grotty that many 
architectures ended up playing some really subtle games there. The whole 
point of the patch is to get rid of the games, but it's entirely possible 
that Microblaze (and others) had crazy things going on that broke when we 
made the ordering more straightforward.

That said, Microblaze is not one of the architectures I would have 
expected to have problems. It has one of the most straightforward 
"flush_thread()" implementations in the whole kernel (it's a no-op ;), and 
that's where most of the hacky things were for the architectures that 
needed the change. And it has no "arch_pick_mmap_layout()" issues or 
anything else that tends to depend on personality bits or whatever.

Microblaze is a no-MMU platform, isn't it? Which binary format does it 
use? It looks like _some_ binaries work (it seems to happily be running a 
shell to actually do those startup scripts) while others have problems. Is 
there a difference between "/bin/sh" and the binaries that seem to be 
problematic (like /bin/mount and /bin/ifup).

Are the failing binaries all setuid ones, for example? Or shared vs 
non-shared? Or ELF vs FLAT or whatever?

		Linus
--
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ