linux-kernel - Re: [braindump][RFC] signals and syscall restarts (Re: [PATCH v2 19/44] metag: Signal handling)

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:	Sat, 8 Dec 2012 18:14:58 +0000
From:	Al Viro <viro@...IV.linux.org.uk>
To:	James Hogan <james.hogan@...tec.com>
Cc:	linux-arch@...r.kernel.org, linux-kernel@...r.kernel.org,
	Arnd Bergmann <arnd@...db.de>,
	Linus Torvalds <torvalds@...ux-foundation.org>
Subject: Re: [braindump][RFC] signals and syscall restarts (Re: [PATCH v2
 19/44] metag: Signal handling)

On Thu, Dec 06, 2012 at 10:09:55PM +0000, Al Viro wrote:

> 	What we need to guarantee is
> * restarts do not happen on signals caught in interrupts or exceptions
> * restarts do not happen on signals caught in sigreturn()
> * restart should happen only once, even if we get through do_signal() many
> times.

BTW, signal caught in sigreturn is *not* something requiring a narrow
race.  It's perfectly normal to have some signals blocked for the
duration of signal handler - the signal itself is blocked by default
unless you have set SA_NODEFER in sa_flags and there's sa_mask allowing
to block an arbitrary set of signals.  Upon return from signal handler
we undo that and if any of the temporary blocked signals has arrived
while we'd been in the handler (e.g. had been raised by the handler itself),
it will be caught as soon as we unblock it, i.e. in sigreturn.

Unfortunately, the testcases are somewhat architecture-dependent.  See, for
example, arm one in commit 653d48b22166db2d8b1515ebe6f9f0f7c95dfc86; there
might be a way to arrange for asm-free equivalent if one played with -O0,
but it's probably not worth the trouble.  That one deals with sigreturn
from signal caught in interrupt; sigreturn from signal caught in syscall
is a bit trickier.  TBH, I don't understand your syscall calling conventions
well enough to cook one up; your restart logics looks really strange.
You leave ->DX[0].U0 modified - fair enough, it doesn't seem to be used
by syscall entry path - *and* you revert ->DX[0].U1 to the state you
used to have on entry.  The thing is, I don't see any place that would
have changed it in between; why do you need that
	regs->REG_SYSCALL = orig_syscall;
in there at all?

BTW, could you (and other folks submitting ports) document the ABI?
See e.g. Documentation/frv/kernel-ABI.txt for fairly decent example...
--
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/