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: Thu, 12 Mar 2015 08:22:18 +0100 From: Mikael Pettersson <mikpelinux@...il.com> To: Andy Lutomirski <luto@...capital.net> Cc: Mikael Pettersson <mikpelinux@...il.com>, Jann Horn <jann@...jh.net>, Linux API <linux-api@...r.kernel.org>, "linux-kernel\@vger.kernel.org" <linux-kernel@...r.kernel.org>, Michael Kerrisk <mtk.manpages@...il.com>, Russell King <linux@....linux.org.uk>, Catalin Marinas <catalin.marinas@....com>, Will Deacon <will.deacon@....com>, Thomas Gleixner <tglx@...utronix.de>, Ingo Molnar <mingo@...hat.com>, "H. Peter Anvin" <hpa@...or.com>, X86 ML <x86@...nel.org>, Jeff Dike <jdike@...toit.com>, Richard Weinberger <richard@....at>, Kees Cook <keescook@...omium.org>, Will Drewry <wad@...omium.org> Subject: Re: [PATCH] Don't allow blocking of signals using sigreturn. Andy Lutomirski writes: > On Wed, Mar 11, 2015 at 2:43 PM, Mikael Pettersson <mikpelinux@...il.com> 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@...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