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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date:	Tue, 23 Sep 2014 15:30:57 +0200
From:	Geert Uytterhoeven <geert@...ux-m68k.org>
To:	Russell King - ARM Linux <linux@....linux.org.uk>
Cc:	Geert Uytterhoeven <geert+renesas@...der.be>,
	Will Deacon <will.deacon@....com>,
	Dietmar Eggemann <dietmar.eggemann@....com>,
	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>,
	Linux-sh list <linux-sh@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Mathieu Poirier <mathieu.poirier@...aro.org>
Subject: Re: [PATCH] ARM: hw_breakpoint: Trap undef instruction exceptions on wake-up

Hi Russell,

On Wed, Sep 17, 2014 at 2:18 PM, Russell King - ARM Linux
<linux@....linux.org.uk> wrote:
> On Wed, Sep 17, 2014 at 01:57:16PM +0200, Geert Uytterhoeven wrote:
>> If power area D4, which contains the Coresight-ETM hardware block, is
>> powered down on R-Mobile A1 (r8a7740), the kernel crashes when
>> suspending from s2ram with:
>>
>>     Internal error: Oops - undefined instruction: 0 [#1] ARM
>>
>> This happens because dbg_cpu_pm_notify() calls reset_ctrl_regs(), which
>> can't access the debug registers as the debug module is powered down.
>>
>> Protect the call to reset_ctrl_regs() by an undefined instruction hook,
>> like was done in commit 0d352e3d006c9589 ("ARM: hw_breakpoint: trap
>> undef instruction exceptions in reset_ctrl_regs") for another caller.
>
> I'd prefer a better solution to this (such as tracking whether the ETM
> block is powered down).  This feels very much like a hack than a good
> solution.

That seems to be something to fit into "[PATCH 00/11 v6] Coresight framework
and drivers" (https://lkml.org/lkml/2014/9/11/733)?

However, if I'm not mistaken, while that series introduces extensive handling
based on the presence of Coresight device nodes in DT, it looks like it doesn't
affect the current direct accesses to the debug registers in hw_breakpoint.c?

For now, do you consider it acceptable to introduce a global bool (defaulting
to true) to track whether accessing the debug registers is allowed?

> Also, the undefined instruction hook was not supposed to be used in this
> way - certainly *not* dynamically like this.  While the lookup of the
> undef handler is done in a safe atomic way, calling the resulting
> function is outside of the locks.

Right, that's definitely not optimal.
I guess this also applies to the existing (ab)users of debug_reg_hook?

Thanks!

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@...ux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds
--
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

Powered by Openwall GNU/*/Linux Powered by OpenVZ