[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <dd4e0dc1-1e5a-4408-6af0-4bf321f38ed4@csgroup.eu>
Date: Tue, 8 Nov 2022 16:21:12 +0000
From: Christophe Leroy <christophe.leroy@...roup.eu>
To: Andrew Donnellan <ajd@...ux.ibm.com>,
"linuxppc-dev@...ts.ozlabs.org" <linuxppc-dev@...ts.ozlabs.org>
CC: "ruscur@...sell.cc" <ruscur@...sell.cc>,
"cmr@...escreens.de" <cmr@...escreens.de>,
"linux-hardening@...r.kernel.org" <linux-hardening@...r.kernel.org>
Subject: Re: [RFC PATCH 4/6] powerpc/powernv: Convert pointers to physical
addresses in OPAL call args
Le 04/11/2022 à 18:27, Andrew Donnellan a écrit :
> A number of OPAL calls take addresses as arguments (e.g. buffers with
> strings to print, etc). These addresses need to be physical addresses, as
> OPAL runs in real mode.
>
> Since the hardware ignores the top two bits of the address in real mode,
> passing addresses in the kernel's linear map works fine even if we don't
> wrap them in __pa().
>
> With VMAP_STACK, however, we're going to have to use vmalloc_to_phys() to
> convert addresses from the stack into an address that OPAL can use.
I think you should then avoid using the stack for all those parameters.
It should be handled just like DMA in drivers : Don't use the stack, use
kmalloc memory instead.
>
> Introduce a new macro, stack_pa(), that uses vmalloc_to_phys() for
> addresses in the vmalloc area, and __pa() for linear map addresses. Add it
> to all the existing callsites where we pass pointers to OPAL.
You should avoid that. Instead, just use kmalloc for local data. If
that's data you get from outside the function, use kmemdup().
Christophe
Powered by blists - more mailing lists