linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
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

  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).