linux-kernel - Re: [RFC] TIF_NOTIFY_RESUME, arch/*/*/*signal*.c and all such

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: <20120427231526.GP6871@ZenIV.linux.org.uk>
Date:	Sat, 28 Apr 2012 00:15:26 +0100
From:	Al Viro <viro@...IV.linux.org.uk>
To:	Roland McGrath <roland@...k.frob.com>
Cc:	Oleg Nesterov <oleg@...hat.com>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	linux-arch@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [RFC] TIF_NOTIFY_RESUME, arch/*/*/*signal*.c and all such

On Fri, Apr 27, 2012 at 02:27:29PM -0700, Roland McGrath wrote:
> The expectation was that every arch would eventually switch on
> CORE_DUMP_USE_REGSET.  (Looks like so far 12 do and so ~16 don't.)
> Certainly avoiding the overhead of user_regset for core dumping is not
> worth any new code complexity or extra arch hooks, since that overhead
> even on the worst-case arch (ia64) has got to be marginal in comparison
> to all the memory-copying and i/o going on.  For imagined potential
> tracing/fancier-debugging cases that might be used in high-throughput
> ways the question would be different, but such uses still remain to be
> implemented.

BTW, speaking of tracehook - you do realize that there are some
architectures where check for user_mode() in do_signal() is not
useless?  I.e. there do_notify_resume() _can_ be called when
returning to kernel mode.  And that'll get you tracehook_notify_resume()
called when you probably wouldn't want it to be; key_replace_session_keyring()
call is not desirable in that situation and the stuff Oleg wants
to add in tracehook_notify_resume() won't be happy with that either...

I think all such architectures need that check lifted to do_notify_resume()
(and the rest needs it killed, of course).  Including x86, by the look
of it - we _probably_ can't get there with TIF_NOTIFY_RESUME and
!user_mode(regs), but I'm not entirely sure of that.  arm is in about the
same situation; alpha, ppc{32,64}, sparc{32,64} and m68k really can't get
there like that (they all check it in the asm glue).  mips probably might,
unless I'm misreading their ret_from_fork()...  Fun.
--
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/