linux-kernel - Re: Page select register restrictions in regmap core

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: <1a62fc39-355c-4885-b5f6-b66f01a1328a@sirena.org.uk>
Date: Tue, 18 Jun 2024 12:35:08 +0100
From: Mark Brown <broonie@...nel.org>
To: Guenter Roeck <linux@...ck-us.net>
Cc: Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	linux-kernel@...r.kernel.org, Armin Wolf <W_Armin@....de>
Subject: Re: Page select register restrictions in regmap core

On Mon, Jun 17, 2024 at 04:15:33PM -0700, Guenter Roeck wrote:
> On 6/17/24 15:47, Mark Brown wrote:
> > On Mon, Jun 17, 2024 at 02:55:09PM -0700, Guenter Roeck wrote:
> > > On 6/17/24 10:22, Mark Brown wrote:

> > > each register address and then accessing, say, the revision register
> > > not as register 0x02 but as register 0x102. I would then define the matching
> > > range from 0x100 .. 0x17f and the window from 0x00..0x7f.

> > That would make the range exactly the same size as the window so there'd
> > be no paging going on and the registers could be accessed directly?  I
> > guess that's another check that should be added...

> I tried to explain this before. The registers in address range 00..0x7f
> are physical, but they are only accessible from page 0 with the exception
> of the page select register. So, sure, the registers are not actually paged,
> but page 0 must be selected to access them. That is the one and only reason
> for specifying that first range and window. It ensures that page 0 is
> selected when accessing the registers. If that wasn't the case, I could
> define a single range for the actually paged addresses in the 0x80..0xff
> window and be done with it.

So surely this means that the entire register map is one window and
there's no point in defining two ranges?  Those registers are paged with
the same selector as the other registers.  At which point you can just
sidestep the issue and be like the other current problematic drivers.

> The non-regmap access all happens in the probe function before regmap is
> initialized. It is needed for basic chip identification, to prevent someone
> from instantiating the driver on a random nvram/eeprom and messing it up
> with attempts to write the page select register. I would not want to be
> held responsible for someone with, say, DDR4 DIMMs force-instantiating
> the spd5118 driver and then complaining about bricked DIMMs.

What some devices do for enumeration if the fully specified regmap won't
work for all is create a trivial regmap used for enumeration, then throw
that away and instantiate a new regmap based on the results of initial
identification, though that wouldn't really work for letting you skip
paging.  I don't see how you avoid handling paging in the probe theough,
unless you just assume that the chip is left on page 0 by whatever came
before.

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