Re: [PATCH] tpm: of: avoid __va() translation for event log address

[Ard Biesheuvel]

On Mon, 28 Sep 2020 at 07:56, Christophe Leroy
<christophe.leroy@xxxxxxxxxx> wrote:
>
>
>
> Le 28/09/2020 à 01:44, Jarkko Sakkinen a écrit :
> > On Fri, Sep 25, 2020 at 09:00:18AM -0300, Jason Gunthorpe wrote:
> >> On Fri, Sep 25, 2020 at 01:29:20PM +0300, Jarkko Sakkinen wrote:
> >>> On Fri, Sep 25, 2020 at 09:00:56AM +0200, Ard Biesheuvel wrote:
> >>>> On Fri, 25 Sep 2020 at 07:56, Jarkko Sakkinen
> >>>> <jarkko.sakkinen@xxxxxxxxxxxxxxx> wrote:
> >>>>>
> >>>>> On Tue, Sep 22, 2020 at 11:41:28AM +0200, Ard Biesheuvel wrote:
> >>>>>> The TPM event log is provided to the OS by the firmware, by loading
> >>>>>> it into an area in memory and passing the physical address via a node
> >>>>>> in the device tree.
> >>>>>>
> >>>>>> Currently, we use __va() to access the memory via the kernel's linear
> >>>>>> map: however, it is not guaranteed that the linear map covers this
> >>>>>> particular address, as we may be running under HIGHMEM on a 32-bit
> >>>>>> architecture, or running firmware that uses a memory type for the
> >>>>>> event log that is omitted from the linear map (such as EfiReserved).
> >>>>>
> >>>>> Makes perfect sense to the level that I wonder if this should have a
> >>>>> fixes tag and/or needs to be backported to the stable kernels?
> >>>>>
> >>>>
> >>>> AIUI, the code was written specifically for ppc64, which is a
> >>>> non-highmem, non-EFI architecture. However, when we start reusing this
> >>>> driver for ARM, this issue could pop up.
> >>>>
> >>>> The code itself has been refactored a couple of times, so I think it
> >>>> will require different versions of the patch for different generations
> >>>> of stable kernels.
> >>>>
> >>>> So perhaps just add Cc: <stable@xxxxxxxxxxxxxxx>, and wait and see how
> >>>> far back it applies cleanly?
> >>>
> >>> Yeah, I think I'll cc it with some note before the diffstat.
> >>>
> >>> I'm thinking to cap it to only 5.x kernels (at least first) unless it is
> >>> dead easy to backport below that.
> >>
> >> I have this vauge recollection of pointing at this before and being
> >> told that it had to be __va for some PPC reason?
> >>
> >> Do check with the PPC people first, I see none on the CC list.
> >>
> >> Jason
> >
> > Thanks, added arch/powerpc maintainers.
> >
>
> As far as I can see, memremap() won't work on PPC32 at least:
>
> IIUC, memremap() calls arch_memremap_wb()
> arch_memremap_wb() calls ioremap_cache()
> In case of failure, then ioremap_wt() and ioremap_wc() are tried.
>
> All ioremap calls end up in __ioremap_caller() which will return NULL in case you try to ioremap RAM.
>
> So the statement "So instead, use memremap(), which will reuse the linear mapping if
> it is valid, or create another mapping otherwise." seems to be wrong, at least for PPC32.
>
> Even for PPC64 which doesn't seem to have the RAM check, I can't see that it will "reuse the linear
> mapping".
>

It is there, please look again. Before any of the above happens,
memremap() will call try_ram_remap() for regions that are covered by a
IORESOURCE_SYSTEM_RAM, and map it using __va() if its PFN is valid and
it is not highmem.

So as far as I can tell, this change has no effect on PPC at all
unless its RAM is not described as IORESOURCE_SYSTEM_RAM.