linux-kernel - Re: try_to_freeze() called with IRQs disabled on ARM

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:	Fri, 2 Sep 2011 18:48:12 +0100
From:	Russell King - ARM Linux <linux@....linux.org.uk>
To:	Ulrich Weigand <Ulrich.Weigand@...ibm.com>
Cc:	Arnd Bergmann <arnd@...db.de>,
	Mark Brown <broonie@...nsource.wolfsonmicro.com>,
	linaro-toolchain@...ts.linaro.org,
	linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
	Martin Schwidefsky <martin.schwidefsky@...ibm.com>,
	Nicolas Pitre <nicolas.pitre@...aro.org>,
	"Rafael J. Wysocki" <rjw@...k.pl>, Tejun Heo <tj@...nel.org>
Subject: Re: try_to_freeze() called with IRQs disabled on ARM

On Fri, Sep 02, 2011 at 07:40:34PM +0200, Ulrich Weigand wrote:
> Russell King - ARM Linux <linux@....linux.org.uk> wrote on 09/02/2011
> 07:22:59 PM:
> > On Fri, Sep 02, 2011 at 04:47:35PM +0200, Ulrich Weigand wrote:
> > > Assume the scenario you initally describe, where a first signal is
> > > ignored and leads to system call restart.  With your latest patch,
> > > you call into syscall_restart which sets everything up to restart
> > > the call (with interrupts disabled).
> >
> > I don't think SIG_IGN signals even set the TIF work flag, so they
> > never even cause a call into do_signal().  Therefore, as far as
> > syscalls go, attempting to send a process (eg) a SIGINT which its
> > handler is set to SIG_IGN results in the process not even being
> > notified about the attempt - we won't even wake up while the
> > syscall is sleeping.
> 
> I don't see why SIG_IGN signals shouldn't set the TIF work flag;
> the decision whether to ignore a signal is only made once we've
> got to get_signal_to_deliver.

Yes, having looked deeper, you seem to be right - but only if the thread
is being ptraced.  If it's not being ptraced, ignored signals don't
make it that far.

And yes, we can end up processing the interrupt before the SVC is
executed, which is still a hole.  So we need to avoid doing the
restart in userspace - which might actually make things easier.
I'll take a look into that over the weekend.
--
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/