linux-kernel - Re: [PATCH] [v1] arch: arm: configs: gxp

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAK8P3a2n=yVfe+QiBvxAXw=5DmVY+Mjaag2s2fq+F=sQngos-Q@mail.gmail.com>
Date:   Wed, 16 Mar 2022 22:06:51 +0100
From:   Arnd Bergmann <arnd@...db.de>
To:     "Verdun, Jean-Marie" <verdun@....com>
Cc:     Arnd Bergmann <arnd@...db.de>,
        "Hawkins, Nick" <nick.hawkins@....com>,
        Russell King <linux@...linux.org.uk>,
        Joel Stanley <joel@....id.au>,
        Andrew Jeffery <andrew@...id.au>,
        Olof Johansson <olof@...om.net>,
        Linux ARM <linux-arm-kernel@...ts.infradead.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] [v1] arch: arm: configs: gxp_defconfig

On Wed, Mar 16, 2022 at 7:54 PM Verdun, Jean-Marie <verdun@....com> wrote:
> >    If you get unknown instruction exceptions, that is clearly a bug that has to be
> >    fixed somewhere. Turning the options off should not be necessary, but we have
> >    to figure out why these crash, and make sure we have correct runtime detection
> >    in place that ensures that any driver code runs only on platforms that have the
> >    corresponding hardware.
>
> >    Do you have any more information about how and why these crash? My first
> >    guess would be that there is something in your DT that describes hardware
> >    that is not actually there. With a correct DTB file, the two options should
> >    not cause any code to run that wouldn't otherwise.
>
> I think I found part of the issue regarding the PERF_EVENTS. In ./arch/arm/kernel/hw_breakpoint.c, the function core_has_os_save_restore is calling the mrc p14 instruction to determine ARM_OSLSR_OSLM0 value. Unfortunately per the ARM Cortex A9 documentation that call is not implemented on such core
> ( https://developer.arm.com/documentation/ddi0388/i/debug/debug-register-summary )
>
> which is leading to an unknown instruction on our ASIC.
>
> Need to figuring out how to workaround that. I will check what ARM_DEBUG_ARCH_V7_ECP14 is supposed to support. We might have either a bug into the way we report the ASIC id or something is weird into the kernel which is assuming that Cortex A9 support this PMU access.

I'm not familiar with the hw_breakpoint.c code, but I can see that the
get_debug_arch()
and core_has_os_save_restore() functions are at least eight years old,
and Cortex-A9
is one of the most common CPU cores, so it would be unlikely that this
is a problem
with the CPU core in general. My best guess would be that your boot
loader code is
missing a bit of initialization that is required to put this into the
correct state.

      Arnd