linux-kernel - Re: [PATCH] ARM: dt: check MPIDR on MP devices built without SMP

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: <2af0a5ad604064d8fcf9febce72f0c23f1a1a1db.camel@suse.de>
Date:   Thu, 03 Oct 2019 21:39:38 +0200
From:   Nicolas Saenz Julienne <nsaenzjulienne@...e.de>
To:     Florian Fainelli <f.fainelli@...il.com>,
        linux-kernel@...r.kernel.org
Cc:     Russell King <linux@...linux.org.uk>,
        linux-arm-kernel@...ts.infradead.org,
        "kernelci.org bot" <bot@...nelci.org>, wahrenst@....net
Subject: Re: [PATCH] ARM: dt: check MPIDR on MP devices built without SMP

On Thu, 2019-10-03 at 11:08 -0700, Florian Fainelli wrote:
> On 10/2/19 4:45 AM, Nicolas Saenz Julienne wrote:
> > Currently, in arm_dt_init_cpu_maps(), the hwid of the boot CPU is read
> > from MPIDR on SMP devices and set to 0 for non SMP. This value is then
> > matched with the DT cpu nodes' reg property in order to find the boot
> > CPU in DT.
> 
> The code you change is about the "mpidr" variable, yet in your commit
> message you refer to "hwid", that is a tad confusing for the reader.

Sorry, it's indeed pretty confusing. I'll send a new version with a fixed
description if there is no major push back.

> > On MP devices build without SMP the cpu DT node contains the expected
> > MPIDR yet the hwid is set to 0. With this the function fails to match
> > the cpus and uses the default CPU logical map. Making it impossible to
> > get the CPU's DT node further down the line. This causes issues with
> > cpufreq-dt, as it triggers warnings when not finding a suitable DT node
> > on CPU0.
> > 
> > Change the way we choose whether to get MPIDR or not. Instead of
> > depending on SMP check the number of CPUs defined in DT. Anything > 1
> > means MPIDR will be available.
> 
> Except if someone accidentally wrote their Device Tree such as to have >
> 1 CPU nodes, yet the CPU is not MP capable and reading the MPIDR
> register does return the expected value, but that is wrong anyway.

An UP device will most likely not have a MPIDR. That said I'm not sure this is
always true. As per ARM1176JZ's TRM[1], the RPi1 CPU, if one was to get the
MPIDR it would raise an undefined exception.

The way I see it's an acceptable outcome as the DT is clearly wrong.

Regarda,
Nicolas

[1] See 3.1.10 Use of the system control coprocessor in
http://infocenter.arm.com/help/topic/com.arm.doc.ddi0333h/DDI0333H_arm1176jzs_r0p7_trm.pdf:

	"Attempting to read from a nonreadable register, or to write to a
	nonwriteable register causes Undefined exceptions."


Download attachment "signature.asc" of type "application/pgp-signature" (489 bytes)