Andy Lutomirski writes: > On Wed, Mar 11, 2015 at 2:43 PM, Mikael Pettersson <[email protected]> > 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-api" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
