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:22:59 +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,
	Nicolas Pitre <nicolas.pitre@...aro.org>,
	"Rafael J. Wysocki" <rjw@...k.pl>, Tejun Heo <tj@...nel.org>,
	Martin Schwidefsky <martin.schwidefsky@...ibm.com>
Subject: Re: try_to_freeze() called with IRQs disabled on ARM

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.

> To really fix this case would probably require some way for the
> debugger to save and restore the restore_block saved state.  This
> is not quite trivial, since it would expose that state to user space,
> effectively creating a new ABI (and probably requiring sanity checks
> to ensure a valid state is restored).  This probably cannot be fixed
> by one architecture for itself, but would need support from common
> kernel code.

Such state would have to be crytographically signed or kept entirely
within the kernel, as it would otherwise mean that you could redirect
the kernel PC to anywhere...
--
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/