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
| ||
|
Date: Wed, 21 Nov 2012 01:53:02 +0000 From: Al Viro <viro@...IV.linux.org.uk> To: Linus Torvalds <torvalds@...ux-foundation.org> Cc: Michal Simek <monstr@...str.eu>, Linux Kernel Mailing List <linux-kernel@...r.kernel.org>, "linux-arch@...r.kernel.org" <linux-arch@...r.kernel.org> Subject: Re: sigaltstack fun (was Re: new execve/kernel_thread design) On Sun, Nov 18, 2012 at 08:45:43AM -1000, Linus Torvalds wrote: > On Sat, Nov 17, 2012 at 7:45 PM, Al Viro <viro@...iv.linux.org.uk> wrote: > > > > Linus, do you have any objections to the above? FWIW, I've a tentative > > patchset in that direction (most of it from the last cycle); right now > > it + stuff currently in signal.git#for-next is at -3.4KLoC and I hadn't > > dealt with the biarch side of things yet... > > I have absolutely no objections. sigaltstack has always been kind of > messy, and made worse by the fact that it gets effectively no testing > (because it's generally not used by normal code and even code that > uses it tends to use it only for very uncommon events). So forcing all > the sigaltstack code into generic code and at least avoiding the > "different architectures can get things subtly - or not so subtly - > wrong in different ways" sounds like a good thing. OK... Intermediate state (do_sigaltstack() guts still need to be cleaned up and distributed between the 4 callers) is in signal.git#master right now; _not_ for merge in that form. Crap found in process: * microblaze, sparc64 and tile (compat side) have the same bug (see above). Fixed in that queue. * score, sh64 and openrisc all tried call do do_sigaltstack() passing it an address of on-stack copy; no, set_fs() was not used. Fixed in that queue. * alpha and c6x do not bother to restore saved altstack settings on sigreturn. * c6x, cris and hexagon don't bother *saving* altstack settings on signal arrival. And yes, it does mean that cris and hexagon call do_sigaltstack() on an unitialized chunk of userland stack. Needs to be fixed (and in a way that could go into -stable, unfortunately ;-/) I hadn't done anything serious with altstack users yet; I'm afraid that this code (i.e. sigframe allocation logics) will also bring a lot of fun weirdness... ;-/ -- 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