linux-hardening - Re: [PATCH 01/28] mfd: Add Microchip ZL3073x support

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: <CAHp75VdkLnm42DS2+kebYUWyXAhyNgswwDNynNJ-weo3DZ=G+Q@mail.gmail.com>
Date: Mon, 14 Apr 2025 20:09:32 +0300
From: Andy Shevchenko <andy.shevchenko@...il.com>
To: Ivan Vecera <ivecera@...hat.com>
Cc: Andy Shevchenko <andy@...nel.org>, netdev@...r.kernel.org, 
	Michal Schmidt <mschmidt@...hat.com>, Vadim Fedorenko <vadim.fedorenko@...ux.dev>, 
	Arkadiusz Kubalewski <arkadiusz.kubalewski@...el.com>, Jiri Pirko <jiri@...nulli.us>, 
	Rob Herring <robh@...nel.org>, Krzysztof Kozlowski <krzk+dt@...nel.org>, Conor Dooley <conor+dt@...nel.org>, 
	Prathosh Satish <Prathosh.Satish@...rochip.com>, Lee Jones <lee@...nel.org>, 
	Kees Cook <kees@...nel.org>, Andrew Morton <akpm@...ux-foundation.org>, devicetree@...r.kernel.org, 
	linux-kernel@...r.kernel.org, linux-hardening@...r.kernel.org
Subject: Re: [PATCH 01/28] mfd: Add Microchip ZL3073x support

On Mon, Apr 14, 2025 at 5:53 PM Ivan Vecera <ivecera@...hat.com> wrote:
> On 14. 04. 25 4:16 odp., Andy Shevchenko wrote:
> > On Mon, Apr 14, 2025 at 5:13 PM Andy Shevchenko
> > <andy.shevchenko@...il.com> wrote:
> >> On Mon, Apr 14, 2025 at 5:10 PM Andy Shevchenko
> >> <andy.shevchenko@...il.com> wrote:
> >>> On Mon, Apr 14, 2025 at 5:07 PM Ivan Vecera <ivecera@...hat.com> wrote:
> >>>> On 14. 04. 25 1:52 odp., Ivan Vecera wrote:
> >
> > ...
> >
> >>>> Long story short, I have to move virtual range outside real address
> >>>> range and apply this offset in the driver code.
> >>>>
> >>>> Is this correct?
> >>>
> >>> Bingo!
> >>>
> >>> And for the offsets, you form them as "page number * page offset +
> >>> offset inside the page".
> >>
> >> Note, for easier reference you may still map page 0 to the virtual
> >> space, but make sure that page 0 (or main page) is available outside
> >> of the ranges, or i.o.w. ranges do not overlap the main page, even if
> >> they include page 0.
> >
> > So, you will have the following layout
> >
> > 0x00 - 0xnn - real registers of page 0.
> >
> > 0x100 - 0xppp -- pages 0 ... N
> >
> > Register access either direct for when direct is required, or as
> > 0x100 + PageSize * Index + RegOffset
>
> Now, get it...
>
> I was a little bit confused by code of _regmap_select_page() that takes
> care of selector_reg.
>
> Btw, why is this needed? why they cannot overlap?
>
> Let's say I have virtual range <0, 0xfff>, window <0, 0xff> and window
> selector 0xff>.
> 1. I'm calling regmap_read(regmap, 0x8f, ...)
> 2. The regmap looks for the range and it finds it (0..0xfff)
> 3. Then it calls _regmap_select_page() that computes:
>     window_offset = (0x8f - 0x000) % 0x100 = 0x8f
>     window_page = (0x8f - 0x000) / 0x100 = 0
> 4. _regmap_select_page() set window selector to 0 and reg is updated to
>     reg = window_start + window_offset = 0x8f
>
> And for window_selector value: regmap_read(regmap, 0xff, ...) is the
> same except _regmap_select_page() checks that the given address is
> selector_reg and won't perform page switching.
>
> When I think about it, in my case there is no normal page, there is only
> volatile register window <0x00-0x7e> and only single direct register
> that is page selector at 0x7f.

Because you are effectively messing up with cache. Also it's not
recommended in general to do such due to some registers that might
need to be accessed directly. And also note, that each time you access
this you will call a selector write _each_ time you want to write the
register in the map (if there is no cache, or if cache is messed up).

-- 
With Best Regards,
Andy Shevchenko