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

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