linux-kernel - Re: [PATCH] ARM: probes: Don't stop the machine if we're in the debugger

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]

Message-ID: <CAD=FV=Xe7hg7ifJ3JAO8StfugMYnojc3SNfsa=gLfWpm0n262A@mail.gmail.com>
Date:	Tue, 25 Aug 2015 12:40:00 -0700
From:	Doug Anderson <dianders@...omium.org>
To:	Kees Cook <keescook@...omium.org>
Cc:	Stephen Boyd <sboyd@...eaurora.org>,
	Nicolas Pitre <nico@...aro.org>,
	Jon Medhurst <tixy@...aro.org>, wangnan0 <wangnan0@...wei.com>,
	Russell King - ARM Linux <linux@....linux.org.uk>,
	LKML <linux-kernel@...r.kernel.org>,
	Aapo Vienamo <avienamo@...dia.com>,
	Rabin Vincent <rabin@....in>,
	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>
Subject: Re: [PATCH] ARM: probes: Don't stop the machine if we're in the debugger

Kees,

On Tue, Aug 25, 2015 at 9:50 AM, Kees Cook <keescook@...omium.org> wrote:
> On Mon, Aug 24, 2015 at 5:19 PM, Stephen Boyd <sboyd@...eaurora.org> wrote:
>> On 08/24/2015 04:58 PM, Douglas Anderson wrote:
>>>
>>> If we're in kgdb then the machine is already stopped.  Trying to stop
>>> it again will cause us to try to sleep, which is not allowed while in
>>> kgdb.  To avoid this problem, only stop the machine when we're not in
>>> kgdb.
>>>
>>> Reported-by: Aapo Vienamo <avienamo@...dia.com>
>>> Suggested-by: Kees Cook <keescook@...omium.org>
>
> I actually suggested using in_atomic_preempt_off() which is I think a
> better catch-all. Could you use that instead, please?

I chose not to use that because (I think) in_atomic_preempt_off()
doesn't guarantee that stop_machine() is not needed.  Said another
way: if in_atomic_preempt_off() returns true then we can't sleep on
the current CPU.  ...but other CPUs may be running.  In this case
technically we need to call stop_machine(), but we'd need to do it in
a way that didn't require sleeping.

In the case of kgdb we know that the machine is stopped and we're
atomic too.  ...so we could certainly fix kgdb by checking for
"atomic", but that would mean there would be other places where we'd
get no warning and (I think) invalid behavior.

Stephen Boyd suggested that I just change this so that we expose a new
function and that makes everything a bit cleaner.  I'll try that.

-Doug
--
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/