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 3/6] powerpc/powernv: Keep MSR in register across OPAL entry/return path
Date: Fri, 4 Nov 2022 18:00:47 +0000 [thread overview]
Message-ID: <1ab4f306-2338-91c2-0329-caa750594977@csgroup.eu> (raw)
In-Reply-To: <20221104172737.391978-4-ajd@linux.ibm.com>
Le 04/11/2022 à 18:27, Andrew Donnellan a écrit :
> When we enter and return from an OPAL call, there's three pieces of state
> we have to save and restore: the stack pointer, the PACA pointer, and the
> MSR. However, there's only two registers that OPAL is guaranteed to
> preserve for us (r1 for the stack pointer and r13 for the PACA), so the MSR
> gets saved on the stack.
>
> This becomes problematic when we enable VMAP_STACK, as we need to re-enable
> translation in order to access the virtually mapped stack... and to
> re-enable translation, we need to restore the MSR.
Do you need to restore MSR really ? Can't you just set MSR_DR to access
the stack then restore MSR ? Or maybe you don't want to do it in two
steps for performance reason ?
>
> Keep the MSR in r13, and instead store the PACA pointer on the stack - we
> can restore the MSR first, then restore the PACA into r13.
>
> Signed-off-by: Andrew Donnellan <ajd@linux.ibm.com>
> ---
> .../powerpc/platforms/powernv/opal-wrappers.S | 43 +++++++++++--------
> 1 file changed, 26 insertions(+), 17 deletions(-)
>
> diff --git a/arch/powerpc/platforms/powernv/opal-wrappers.S b/arch/powerpc/platforms/powernv/opal-wrappers.S
> index 0ed95f753416..d692869ee0ce 100644
> --- a/arch/powerpc/platforms/powernv/opal-wrappers.S
> +++ b/arch/powerpc/platforms/powernv/opal-wrappers.S
> @@ -23,40 +23,49 @@
> _GLOBAL_TOC(__opal_call)
> mflr r0
> std r0,PPC_LR_STKOFF(r1)
> - ld r12,STK_PARAM(R12)(r1)
> - li r0,MSR_IR|MSR_DR|MSR_LE
> - andc r12,r12,r0
> LOAD_REG_ADDR(r11, opal_return)
> mtlr r11
> LOAD_REG_ADDR(r11, opal)
> ld r2,0(r11)
> ld r11,8(r11)
> mtspr SPRN_HSRR0,r11
> - mtspr SPRN_HSRR1,r12
> +
> /* set token to r0 */
> ld r0,STK_PARAM(R11)(r1)
> +
> + /*
> + * We need to keep the MSR value in a register that is preserved by
> + * OPAL, so that we don't need to access the stack before we restore
> + * the MSR, as the stack may be vmalloced and thus require MMU.
> + *
> + * Move the PACA from R13 into the stack red zone, and put MSR in R13.
> + */
> + std r13,-8(r1)
> + ld r13,STK_PARAM(R12)(r1)
> +
> + /* Switch off MMU, LE */
> + li r11,MSR_IR|MSR_DR|MSR_LE
> + andc r11,r13,r11
> +
> + mtspr SPRN_HSRR1,r11
> hrfid
> opal_return:
> /*
> * Restore MSR on OPAL return. The MSR is set to big-endian.
> */
> #ifdef __BIG_ENDIAN__
> - ld r11,STK_PARAM(R12)(r1)
> - mtmsrd r11
> + mtmsrd r13
> #else
> /* Endian can only be switched with rfi, must byte reverse MSR load */
> - .short 0x4039 /* li r10,STK_PARAM(R12) */
> - .byte (STK_PARAM(R12) >> 8) & 0xff
> - .byte STK_PARAM(R12) & 0xff
> -
> - .long 0x280c6a7d /* ldbrx r11,r10,r1 */
> - .long 0x05009f42 /* bcl 20,31,$+4 */
> - .long 0xa602487d /* mflr r10 */
> - .long 0x14004a39 /* addi r10,r10,20 */
> - .long 0xa64b5a7d /* mthsrr0 r10 */
> - .long 0xa64b7b7d /* mthsrr1 r11 */
> - .long 0x2402004c /* hrfid */
> + .long 0x05009f42 /* bcl 20,31,$+4 (LR <- next insn addr) */
> + .long 0xa602487d /* mflr r10 */
> + .long 0x14004a39 /* addi r10,r10,20 (r10 <- addr after #endif) */
> + .long 0xa64b5a7d /* mthsrr0 r10 (new NIP) */
> + .long 0xa64bbb7d /* mthsrr1 r13 (new MSR) */
> + .long 0x2402004c /* hrfid */
> #endif
> + /* Restore PACA */
> + ld r13,-8(r1)
> LOAD_PACA_TOC()
> ld r0,PPC_LR_STKOFF(r1)
> mtlr r0
next prev parent reply other threads:[~2022-11-04 18:02 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 [this message]
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
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=1ab4f306-2338-91c2-0329-caa750594977@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).