linux-kernel - Re: [PATCH V4 05/16] soc: tegra: pmc: Avoid extra remapping of PMC registers

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: <5697F0AD.9080601@nvidia.com>
Date:	Thu, 14 Jan 2016 19:02:05 +0000
From:	Jon Hunter <jonathanh@...dia.com>
To:	Thierry Reding <thierry.reding@...il.com>
CC:	Philipp Zabel <p.zabel@...gutronix.de>,
	Stephen Warren <swarren@...dotorg.org>,
	Alexandre Courbot <gnurou@...il.com>,
	Rafael Wysocki <rjw@...ysocki.net>,
	Kevin Hilman <khilman@...nel.org>,
	Ulf Hansson <ulf.hansson@...aro.org>,
	Rob Herring <robh+dt@...nel.org>,
	Pawel Moll <pawel.moll@....com>,
	Mark Rutland <mark.rutland@....com>,
	Ian Campbell <ijc+devicetree@...lion.org.uk>,
	Kumar Gala <galak@...eaurora.org>,
	Vince Hsu <vinceh@...dia.com>, <devicetree@...r.kernel.org>,
	<linux-kernel@...r.kernel.org>, <linux-tegra@...r.kernel.org>,
	<linux-pm@...r.kernel.org>
Subject: Re: [PATCH V4 05/16] soc: tegra: pmc: Avoid extra remapping of PMC
 registers


On 14/01/16 17:24, Thierry Reding wrote:
> * PGP Signed by an unknown key
> 
> On Thu, Jan 14, 2016 at 04:35:28PM +0000, Jon Hunter wrote:
>>
>> On 14/01/16 13:45, Thierry Reding wrote:
>>>> Old Signed by an unknown key
>>>
>>> On Fri, Dec 04, 2015 at 02:57:06PM +0000, Jon Hunter wrote:
>>>> During early initialisation, the PMC registers are mapped and the PMC SoC
>>>> data is populated in the PMC data structure. This allows other drivers
>>>> access the PMC register space, via the public tegra PMC APIs, prior to
>>>> probing the PMC device.
>>>>
>>>> When the PMC device is probed, the PMC registers are mapped again and if
>>>> successful the initial mapping is freed. If the probing of the PMC device
>>>> fails after the registers are remapped, then the registers will be
>>>> unmapped and hence the pointer to the PMC registers will be invalid. This
>>>> could lead to a potential crash, because once the PMC SoC data pointer is
>>>> populated, the driver assumes that the PMC register mapping is also valid
>>>> and a user calling any of the public tegra PMC APIs could trigger an
>>>> exception because these APIs don't check that the mapping is still valid.
>>>>
>>>> Rather than adding a test to see if the PMC register mapping is valid,
>>>> fix this by removing the second mapping of the PMC registers and reserve
>>>> the memory region for the PMC registers during early initialisation where
>>>> the initial mapping is created. During the probing of the PMC simply check
>>>> that the PMC registers have been mapped.
>>>>
>>>> Signed-off-by: Jon Hunter <jonathanh@...dia.com>
>>>> ---
>>>>  drivers/soc/tegra/pmc.c | 19 +++++++++----------
>>>>  1 file changed, 9 insertions(+), 10 deletions(-)

[snip]

> Ah yes, of course. You could still do it with just the two pointers if
> you keep the code as-is and revert back to the backed up value in case
> of errors. Along this line:
> 
> 	base = pmc->base;
> 
> 	pmc->base = devm_ioremap_resource(&pdev->dev, res);
> 
> 	/* on success */
> 	iounmap(base);
> 
> 	/* on error */
> 	pmc->base = base;
> 
> These pointer assignments should be atomic, so no potential for races
> there. I've attached a patch which should do the trick, though I have
> not tested it.

Right, but I am concerned about someone calling tegra_powergate_set()
(which with patch 6 of this series) will poll for the state to change. I
am not sure we can guarantee the pointer does not change while this is
happening.

>>               Even so, I was not sure if there could be a race here.
>> Ideally, you would lock, but then you need to lock everywhere that you
>> use base. Given that my patch still provides a /proc/iomem entry with a
>> valid name, it seems best to me.
> 
> The primary reason for the "takeover" is that except for the extra
> iounmap() and pointer swapping the tegra_pmc_probe() function is really
> a standard driver implementation. The idea behind this had always been
> that it should be possible to easily convert this to a proper driver if
> either we ended up with PSCI exclusively for SMP or defer SMP setup
> until the PMC driver had been probed, so that we could get rid of the
> early_initcall().

I agree it is cleaner, however, I am still concerned there could still
be a race.

Jon