Here's an incremental fix that can be folded into the patch.
Segher Boessenkool's on February 26, 2020 7:20 am:
> Hi!
>
> On Wed, Feb 26, 2020 at 03:35:35AM +1000, Nicholas Piggin wrote:
>> Kernel addresses and potentially other sensitive data could be leaked
>> in volatile registers after a syscall.
>
>> cmpdi r3,0
>> bne .Lsyscall_restore_regs
>> + li r0,0
>> + li r4,0
>> + li r5,0
>> + li r6,0
>> + li r7,0
>> + li r8,0
>> + li r9,0
>> + li r10,0
>> + li r11,0
>> + li r12,0
>> + mtctr r0
>> + mtspr SPRN_XER,r0
>> .Lsyscall_restore_regs_cont:
>
> What about LR? Is that taken care of later?
>
> This also deserves a big fat comment imo, it is very important after
> all, and not so obvious.
>
>
> Segher
>
Signed-off-by: Nicholas Piggin <npig...@gmail.com>
---
arch/powerpc/kernel/entry_64.S | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/powerpc/kernel/entry_64.S b/arch/powerpc/kernel/entry_64.S
index 0e2c56573a41..ea534375250b 100644
--- a/arch/powerpc/kernel/entry_64.S
+++ b/arch/powerpc/kernel/entry_64.S
@@ -135,6 +135,7 @@ END_FTR_SECTION_IFCLR(CPU_FTR_STCX_CHECKS_ADDRESS)
cmpdi r3,0
bne .Lsyscall_restore_regs
+ /* Zero volatile regs that may contain sensitive kernel data */
li r0,0
li r4,0
li r5,0
--
2.23.0
