From: Christophe Leroy <christophe.leroy@csgroup.eu>
To: Andrew Donnellan <ajd@linux.ibm.com>,
"linuxppc-dev@lists.ozlabs.org" <linuxppc-dev@lists.ozlabs.org>
Cc: "linux-hardening@vger.kernel.org"
<linux-hardening@vger.kernel.org>,
"cmr@bluescreens.de" <cmr@bluescreens.de>
Subject: Re: [RFC PATCH 4/6] powerpc/powernv: Convert pointers to physical addresses in OPAL call args
Date: Tue, 8 Nov 2022 16:21:12 +0000 [thread overview]
Message-ID: <dd4e0dc1-1e5a-4408-6af0-4bf321f38ed4@csgroup.eu> (raw)
In-Reply-To: <20221104172737.391978-5-ajd@linux.ibm.com>
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
next prev parent reply other threads:[~2022-11-08 16:22 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-11-04 17:27 [RFC PATCH 0/6] VMAP_STACK support for book3s64 Andrew Donnellan
2022-11-04 17:27 ` [RFC PATCH 1/6] powerpc/64s: Fix assembly to support larger values of THREAD_SIZE Andrew Donnellan
2022-11-04 17:51 ` Christophe Leroy
2023-04-26 7:03 ` Andrew Donnellan
2022-11-04 17:27 ` [RFC PATCH 2/6] powerpc/64s: Helpers to switch between linear and vmapped stack pointers Andrew Donnellan
2022-11-05 8:00 ` Christophe Leroy
2022-11-05 19:28 ` Christophe Leroy
2022-11-07 12:38 ` Nicholas Piggin
2022-11-04 17:27 ` [RFC PATCH 3/6] powerpc/powernv: Keep MSR in register across OPAL entry/return path Andrew Donnellan
2022-11-04 18:00 ` Christophe Leroy
2022-11-04 17:27 ` [RFC PATCH 4/6] powerpc/powernv: Convert pointers to physical addresses in OPAL call args Andrew Donnellan
2022-11-07 0:00 ` Russell Currey
2022-11-08 16:21 ` Christophe Leroy [this message]
2022-11-04 17:27 ` [RFC PATCH 5/6] powerpc/powernv/idle: Convert stack pointer to physical address Andrew Donnellan
2022-11-08 16:17 ` Christophe Leroy
2022-11-04 17:27 ` [RFC PATCH 6/6] powerpc/64s: Enable CONFIG_VMAP_STACK Andrew Donnellan
2022-11-05 17:07 ` Christophe Leroy
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=dd4e0dc1-1e5a-4408-6af0-4bf321f38ed4@csgroup.eu \
--to=christophe.leroy@csgroup.eu \
--cc=ajd@linux.ibm.com \
--cc=cmr@bluescreens.de \
--cc=linux-hardening@vger.kernel.org \
--cc=linuxppc-dev@lists.ozlabs.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).