Re: [PATCH] Don't allow blocking of signals using sigreturn.

From: Mikael Pettersson
Date: Thu Mar 12 2015 - 03:22:29 EST

Andy Lutomirski writes:
> On Wed, Mar 11, 2015 at 2:43 PM, Mikael Pettersson <mikpelinux@xxxxxxxxx> wrote:
> > Jann Horn writes:
> > > Or should I throw this patch away and write a patch
> > > for the prctl() manpage instead that documents that
> > > being able to call sigreturn() implies being able to
> > > effectively call sigprocmask(), at least on some
> > > architectures like X86?
> >
> > Well, that is the semantics of sigreturn(). It is essentially
> > setcontext() [which includes the actions of sigprocmask()], but
> > with restrictions on parameter placement (at least on x86).
> >
> > You could introduce some setting to restrict that aspect for
> > seccomp processes, but you can't change this for normal processes
> > without breaking things.
> Which leads to the interesting question: does anyone ever call
> sigreturn with a different signal mask than the kernel put there
> during signal delivery

Yes. Either a sigfillset();sigdelset(SIGSEGV), or a copy of the
thread's sigmask from a previous sigframe.

> or, even more strangely, with a totally made up
> context?

Not "totally made up", but certainly with adjustments(*) made to
both GPRs and PC. In a different piece of SW: FPU controls.

(*) Rolling back or force-committing a micro-transaction until
PC+GPRs represent the state at an original instruction boundary.
This was in a product using dynamic binary instrumentation.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at