Re: [PATCH v4 19/20] powerpc/64s: Clear gprs on interrupt routine entry in Book3S

["Nicholas Piggin" <npiggin@gmail.com>]

On Thu Sep 15, 2022 at 4:55 PM AEST, Rohan McLure wrote:
>
>
> > On 12 Sep 2022, at 10:15 pm, Nicholas Piggin <npiggin@gmail.com> wrote:
> > 
> > On Wed Aug 24, 2022 at 12:05 PM AEST, Rohan McLure wrote:
> >> Zero GPRS r0, r2-r11, r14-r31, on entry into the kernel for all
> >> other interrupt sources to limit influence of user-space values
> >> in potential speculation gadgets. The remaining gprs are overwritten by
> >> entry macros to interrupt handlers, irrespective of whether or not a
> >> given handler consumes these register values.
> >> 
> >> Prior to this commit, r14-r31 are restored on a per-interrupt basis at
> >> exit, but now they are always restored. Remove explicit REST_NVGPRS
> >> invocations as non-volatiles must now always be restored. 32-bit systems
> >> do not clear user registers on interrupt, and continue to depend on the
> >> return value of interrupt_exit_user_prepare to determine whether or not
> >> to restore non-volatiles.
> >> 
> >> The mmap_bench benchmark in selftests should rapidly invoke pagefaults.
> >> See ~0.8% performance regression with this mitigation, but this
> >> indicates the worst-case performance due to heavier-weight interrupt
> >> handlers.
> > 
> > Ow, my heart :(
> > 
> > Are we not keeping a CONFIG option to rid ourselves of this vile
> > performance robbing thing? Are we getting rid of the whole
> > _TIF_RESTOREALL thing too, or does PPC32 want to keep it?
>
> I see no reason not to include a CONFIG option for this 
> mitigation here other than simplicity. Any suggestions for a name?
> I’m thinking PPC64_SANITIZE_INTERRUPTS. Defaults on Book3E_64, optional
> on Book3S_64.

INTERRUPT_SANITIZE_REGISTERS perhaps?

>
> >> 
> >> Signed-off-by: Rohan McLure <rmclure@linux.ibm.com>
> >> ---
> >> V1 -> V2: Add benchmark data
> >> V2 -> V3: Use ZEROIZE_GPR{,S} macro renames, clarify
> >> interrupt_exit_user_prepare changes in summary.
> >> ---
> >> arch/powerpc/kernel/exceptions-64s.S | 21 ++++++++-------------
> >> arch/powerpc/kernel/interrupt_64.S   |  9 ++-------
> >> 2 files changed, 10 insertions(+), 20 deletions(-)
> >> 
> >> diff --git a/arch/powerpc/kernel/exceptions-64s.S b/arch/powerpc/kernel/exceptions-64s.S
> >> index a3b51441b039..038e42fb2182 100644
> >> --- a/arch/powerpc/kernel/exceptions-64s.S
> >> +++ b/arch/powerpc/kernel/exceptions-64s.S
> >> @@ -502,6 +502,7 @@ DEFINE_FIXED_SYMBOL(\name\()_common_real, text)
> >> 	std	r10,0(r1)		/* make stack chain pointer	*/
> >> 	std	r0,GPR0(r1)		/* save r0 in stackframe	*/
> >> 	std	r10,GPR1(r1)		/* save r1 in stackframe	*/
> >> +	ZEROIZE_GPR(0)
> >> 
> >> 	/* Mark our [H]SRRs valid for return */
> >> 	li	r10,1
> >> @@ -538,14 +539,18 @@ END_FTR_SECTION_IFSET(CPU_FTR_HAS_PPR)
> >> 	ld	r10,IAREA+EX_R10(r13)
> >> 	std	r9,GPR9(r1)
> >> 	std	r10,GPR10(r1)
> >> +	ZEROIZE_GPRS(9, 10)
> > 
> > You use 9/10 right afterwards, this'd have to move down to where
> > you zero r11 at least.
> > 
> >> 	ld	r9,IAREA+EX_R11(r13)	/* move r11 - r13 to stackframe	*/
> >> 	ld	r10,IAREA+EX_R12(r13)
> >> 	ld	r11,IAREA+EX_R13(r13)
> >> 	std	r9,GPR11(r1)
> >> 	std	r10,GPR12(r1)
> >> 	std	r11,GPR13(r1)
> >> +	/* keep r12 ([H]SRR1/MSR), r13 (PACA) for interrupt routine */
> >> +	ZEROIZE_GPR(11)
> > 
> > Kernel always has to keep r13 so no need to comment that. Keeping r11,
> > is that for those annoying fp_unavailable etc handlers?
> > 
> > There's probably not much a user can do with this, given they're set
> > from the MSR. Use can influence some bits of its MSR though. So long
> > as we're being paranoid, you could add an IOPTION to retain r11 only for
> > the handlers that need it, or have them load it from MSR and zero it
> > here.
>
> Good suggestion. Presume you’re referring to r12 here. I might go the
> IOPTION route.

Yeah r12, I think you need it because some of those assembly handlers
expect it there to check SRR1 bits. Having an IOPTION is probably good
and it documents that quirk of those handlers. That's bitten me before.

Thanks,
Nick