All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH] arm64: entry: SP Alignment Fault doesn't write to FAR_EL1
@ 2019-07-17 16:56 James Morse
  2019-07-22 10:34 ` Will Deacon
  0 siblings, 1 reply; 3+ messages in thread
From: James Morse @ 2019-07-17 16:56 UTC (permalink / raw)
  To: linux-arm-kernel; +Cc: Mark Rutland, Catalin Marinas, Will Deacon, James Morse

Comparing the arm-arm's  pseudocode for AArch64.PCAlignmentFault() with
AArch64.SPAlignmentFault() shows that SP faults don't copy the faulty-SP
to FAR_EL1, but this is where we read from, and the address we provide
to user-space with the BUS_ADRALN signal.

This value will be UNKNOWN due to the previous ERET to user-space.
If the last value is preserved, on systems with KASLR or KPTI this will
be the user-space link-register left in FAR_EL1 by tramp_exit().

Fix this to retrieve the original sp_el0 value, and pass this to
do_sp_pc_fault().

Fixes: 60ffc30d5652 ("arm64: Exception handling")
Signed-off-by: James Morse <james.morse@arm.com>
---
 arch/arm64/kernel/entry.S | 25 ++++++++++++++++++++-----
 1 file changed, 20 insertions(+), 5 deletions(-)

diff --git a/arch/arm64/kernel/entry.S b/arch/arm64/kernel/entry.S
index 165da78815c5..023e533c537e 100644
--- a/arch/arm64/kernel/entry.S
+++ b/arch/arm64/kernel/entry.S
@@ -743,9 +743,9 @@ el0_sync:
 	ccmp	x24, #ESR_ELx_EC_WFx, #4, ne
 	b.eq	el0_sys
 	cmp	x24, #ESR_ELx_EC_SP_ALIGN	// stack alignment exception
-	b.eq	el0_sp_pc
+	b.eq	el0_sp
 	cmp	x24, #ESR_ELx_EC_PC_ALIGN	// pc alignment exception
-	b.eq	el0_sp_pc
+	b.eq	el0_pc
 	cmp	x24, #ESR_ELx_EC_UNKNOWN	// unknown exception in EL0
 	b.eq	el0_undef
 	cmp	x24, #ESR_ELx_EC_BREAKPT_LOW	// debug exception in EL0
@@ -769,7 +769,7 @@ el0_sync_compat:
 	cmp	x24, #ESR_ELx_EC_FP_EXC32	// FP/ASIMD exception
 	b.eq	el0_fpsimd_exc
 	cmp	x24, #ESR_ELx_EC_PC_ALIGN	// pc alignment exception
-	b.eq	el0_sp_pc
+	b.eq	el0_pc
 	cmp	x24, #ESR_ELx_EC_UNKNOWN	// unknown exception in EL0
 	b.eq	el0_undef
 	cmp	x24, #ESR_ELx_EC_CP15_32	// CP15 MRC/MCR trap
@@ -869,9 +869,24 @@ el0_fpsimd_exc:
 	mov	x1, sp
 	bl	do_fpsimd_exc
 	b	ret_to_user
-el0_sp_pc:
+el0_sp:
 	/*
-	 * Stack or PC alignment exception handling
+	 * Stack alignment exception handling
+	 */
+	gic_prio_kentry_setup tmp=x0
+	enable_da_f
+#ifdef CONFIG_TRACE_IRQFLAGS
+	bl	trace_hardirqs_off
+#endif
+	ct_user_exit
+	ldr	x0, [sp, #S_SP]
+	mov	x1, x25
+	mov	x2, sp
+	bl	do_sp_pc_abort
+	b	ret_to_user
+el0_pc:
+	/*
+	 * PC alignment exception handling
 	 */
 	mrs	x26, far_el1
 	gic_prio_kentry_setup tmp=x0
-- 
2.20.1


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply related	[flat|nested] 3+ messages in thread
* Re: [PATCH] arm64: entry: SP Alignment Fault doesn't write to FAR_EL1
  2019-07-17 16:56 [PATCH] arm64: entry: SP Alignment Fault doesn't write to FAR_EL1 James Morse
@ 2019-07-22 10:34 ` Will Deacon
  2019-07-22 14:27   ` James Morse
  0 siblings, 1 reply; 3+ messages in thread
From: Will Deacon @ 2019-07-22 10:34 UTC (permalink / raw)
  To: James Morse; +Cc: Mark Rutland, Catalin Marinas, linux-arm-kernel

Hi James,

On Wed, Jul 17, 2019 at 05:56:02PM +0100, James Morse wrote:
> Comparing the arm-arm's  pseudocode for AArch64.PCAlignmentFault() with
> AArch64.SPAlignmentFault() shows that SP faults don't copy the faulty-SP
> to FAR_EL1, but this is where we read from, and the address we provide
> to user-space with the BUS_ADRALN signal.
> 
> This value will be UNKNOWN due to the previous ERET to user-space.
> If the last value is preserved, on systems with KASLR or KPTI this will
> be the user-space link-register left in FAR_EL1 by tramp_exit().
> 
> Fix this to retrieve the original sp_el0 value, and pass this to
> do_sp_pc_fault().
> 
> Fixes: 60ffc30d5652 ("arm64: Exception handling")
> Signed-off-by: James Morse <james.morse@arm.com>
> ---
>  arch/arm64/kernel/entry.S | 25 ++++++++++++++++++++-----
>  1 file changed, 20 insertions(+), 5 deletions(-)
> 
> diff --git a/arch/arm64/kernel/entry.S b/arch/arm64/kernel/entry.S
> index 165da78815c5..023e533c537e 100644
> --- a/arch/arm64/kernel/entry.S
> +++ b/arch/arm64/kernel/entry.S
> @@ -743,9 +743,9 @@ el0_sync:
>  	ccmp	x24, #ESR_ELx_EC_WFx, #4, ne
>  	b.eq	el0_sys
>  	cmp	x24, #ESR_ELx_EC_SP_ALIGN	// stack alignment exception
> -	b.eq	el0_sp_pc
> +	b.eq	el0_sp
>  	cmp	x24, #ESR_ELx_EC_PC_ALIGN	// pc alignment exception
> -	b.eq	el0_sp_pc
> +	b.eq	el0_pc
>  	cmp	x24, #ESR_ELx_EC_UNKNOWN	// unknown exception in EL0
>  	b.eq	el0_undef
>  	cmp	x24, #ESR_ELx_EC_BREAKPT_LOW	// debug exception in EL0
> @@ -769,7 +769,7 @@ el0_sync_compat:
>  	cmp	x24, #ESR_ELx_EC_FP_EXC32	// FP/ASIMD exception
>  	b.eq	el0_fpsimd_exc
>  	cmp	x24, #ESR_ELx_EC_PC_ALIGN	// pc alignment exception
> -	b.eq	el0_sp_pc
> +	b.eq	el0_pc
>  	cmp	x24, #ESR_ELx_EC_UNKNOWN	// unknown exception in EL0
>  	b.eq	el0_undef
>  	cmp	x24, #ESR_ELx_EC_CP15_32	// CP15 MRC/MCR trap
> @@ -869,9 +869,24 @@ el0_fpsimd_exc:
>  	mov	x1, sp
>  	bl	do_fpsimd_exc
>  	b	ret_to_user
> -el0_sp_pc:
> +el0_sp:
>  	/*
> -	 * Stack or PC alignment exception handling
> +	 * Stack alignment exception handling
> +	 */
> +	gic_prio_kentry_setup tmp=x0
> +	enable_da_f
> +#ifdef CONFIG_TRACE_IRQFLAGS
> +	bl	trace_hardirqs_off
> +#endif
> +	ct_user_exit
> +	ldr	x0, [sp, #S_SP]
> +	mov	x1, x25
> +	mov	x2, sp
> +	bl	do_sp_pc_abort
> +	b	ret_to_user
> +el0_pc:
> +	/*
> +	 * PC alignment exception handling

Given that this really isn't a fast path, I think it's preferable to avoid
duplicating the entry code and instead just have something like:

@@ -858,11 +858,15 @@ el0_fpsimd_exc:
 	mov	x1, sp
 	bl	do_fpsimd_exc
 	b	ret_to_user
+el0_sp:
+	ldr	x26, [sp, #S_SP]
+	b	el0_sp_pc
+el0_pc:
+	mrs	x26, far_el1
 el0_sp_pc:
 	/*
 	 * Stack or PC alignment exception handling
 	 */
-	mrs	x26, far_el1
 	gic_prio_kentry_setup tmp=x0
 	enable_da_f
 #ifdef CONFIG_TRACE_IRQFLAGS

I also think we should do the same thing for the EL1 case, even though
the address is currently ignored by the C handler.

What do you reckon?

Will

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply	[flat|nested] 3+ messages in thread
* Re: [PATCH] arm64: entry: SP Alignment Fault doesn't write to FAR_EL1
  2019-07-22 10:34 ` Will Deacon
@ 2019-07-22 14:27   ` James Morse
  0 siblings, 0 replies; 3+ messages in thread
From: James Morse @ 2019-07-22 14:27 UTC (permalink / raw)
  To: Will Deacon; +Cc: Mark Rutland, Catalin Marinas, linux-arm-kernel

Hi Will,

On 22/07/2019 11:34, Will Deacon wrote:
> Hi James,
> 
> On Wed, Jul 17, 2019 at 05:56:02PM +0100, James Morse wrote:
>> Comparing the arm-arm's  pseudocode for AArch64.PCAlignmentFault() with
>> AArch64.SPAlignmentFault() shows that SP faults don't copy the faulty-SP
>> to FAR_EL1, but this is where we read from, and the address we provide
>> to user-space with the BUS_ADRALN signal.
>>
>> This value will be UNKNOWN due to the previous ERET to user-space.
>> If the last value is preserved, on systems with KASLR or KPTI this will
>> be the user-space link-register left in FAR_EL1 by tramp_exit().
>>
>> Fix this to retrieve the original sp_el0 value, and pass this to
>> do_sp_pc_fault().

>> diff --git a/arch/arm64/kernel/entry.S b/arch/arm64/kernel/entry.S
>> index 165da78815c5..023e533c537e 100644
>> --- a/arch/arm64/kernel/entry.S
>> +++ b/arch/arm64/kernel/entry.S

>> @@ -869,9 +869,24 @@ el0_fpsimd_exc:
>>  	mov	x1, sp
>>  	bl	do_fpsimd_exc
>>  	b	ret_to_user
>> -el0_sp_pc:
>> +el0_sp:
>>  	/*
>> -	 * Stack or PC alignment exception handling
>> +	 * Stack alignment exception handling
>> +	 */
>> +	gic_prio_kentry_setup tmp=x0
>> +	enable_da_f
>> +#ifdef CONFIG_TRACE_IRQFLAGS
>> +	bl	trace_hardirqs_off
>> +#endif
>> +	ct_user_exit
>> +	ldr	x0, [sp, #S_SP]
>> +	mov	x1, x25
>> +	mov	x2, sp
>> +	bl	do_sp_pc_abort
>> +	b	ret_to_user
>> +el0_pc:
>> +	/*
>> +	 * PC alignment exception handling

> Given that this really isn't a fast path, I think it's preferable to avoid
> duplicating the entry code and instead just have something like:
> 
> @@ -858,11 +858,15 @@ el0_fpsimd_exc:
>  	mov	x1, sp
>  	bl	do_fpsimd_exc
>  	b	ret_to_user
> +el0_sp:
> +	ldr	x26, [sp, #S_SP]
> +	b	el0_sp_pc
> +el0_pc:
> +	mrs	x26, far_el1
>  el0_sp_pc:
>  	/*
>  	 * Stack or PC alignment exception handling
>  	 */
> -	mrs	x26, far_el1
>  	gic_prio_kentry_setup tmp=x0
>  	enable_da_f
>  #ifdef CONFIG_TRACE_IRQFLAGS
> 

I'll do it this way. I came to this from Mark's series that moves this to C, where it ends
up being duplicated, so I didn't think very long about it.


> I also think we should do the same thing for the EL1 case, even though
> the address is currently ignored by the C handler.

> What do you reckon?

I wrote that patch, but then found we don't fix misaligned EL1 stacks, so that code never
runs. We end up panic()ing on the overflow stack.

There was a series from Julien Thierry[0] that fixed this, but it looks like the
conclusion was gcc would never generate code that misaligns the stack.

If you like I can fix the existing el1_sp_pc, just because its broken. We don't want to
re-discover this bug in the future.


Thanks,

James

[0] https://www.spinics.net/lists/arm-kernel/msg686173.html

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply	[flat|nested] 3+ messages in thread
end of thread, other threads:[~2019-07-22 14:27 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-07-17 16:56 [PATCH] arm64: entry: SP Alignment Fault doesn't write to FAR_EL1 James Morse
2019-07-22 10:34 ` Will Deacon
2019-07-22 14:27   ` James Morse

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.