Re: [PATCH 2/5] arm64: Handle UNDEF in the EL2 stub vectors

On Fri, 13 Aug 2021 19:17:56 +0100,
Robin Murphy [off-list ref] wrote:

On 2021-08-13 18:41, Marc Zyngier wrote:

quoted

On Fri, 13 Aug 2021 14:08:23 +0100,
Robin Murphy [off-list ref] wrote:

quoted

On 2021-08-12 20:02, Marc Zyngier wrote:

quoted

As we want to handle the silly case where HVC has been disabled
from EL3, augment our ability to handle exception at EL2.

Check for unknown exceptions (usually UNDEF) coming from EL2,
and treat them as a failing HVC call into the stubs. While
this isn't great and obviously doesn't catter for the gigantic
range of possible exceptions, it isn't any worse than what we
have today.

Just don't try and use it for anything else.

Signed-off-by: Marc Zyngier <maz@kernel.org>
---
   arch/arm64/kernel/hyp-stub.S | 19 ++++++++++++++++++-
   1 file changed, 18 insertions(+), 1 deletion(-)

diff --git a/arch/arm64/kernel/hyp-stub.S b/arch/arm64/kernel/hyp-stub.S
index 43d212618834..026a34515b21 100644
--- a/arch/arm64/kernel/hyp-stub.S
+++ b/arch/arm64/kernel/hyp-stub.S

@@ -46,7 +46,16 @@ SYM_CODE_END(__hyp_stub_vectors)
   	.align 11
     SYM_CODE_START_LOCAL(elx_sync)
-	cmp	x0, #HVC_SET_VECTORS
+	mrs	x4, spsr_el2
+	and	x4, x4, #PSR_MODE_MASK
+	orr	x4, x4, #1
+	cmp	x4, #PSR_MODE_EL2h
+	b.ne	0f
+	mrs	x4, esr_el2
+	eor	x4, x4, #ESR_ELx_IL
+	cbz	x4, el2_undef

Hmm, might it be neater to check ESR_EL2.ISS to see if we landed here
for any reason *other* than a successfully-executed HVC?

We absolutely could. However, the sixpence question (yes, that's the
Brexit effect for you) is "what do you do with exceptions that are
neither UNDEF now HVC?".

We are taking a leap of faith by assuming that the only thing that
will UNDEF at EL2 while the stubs are installed is HVC. If anything
else occurs, I have no idea what to do with it. I guess we could always
ignore it instead of treating it as a HVC (as it is done at the
moment).

Right, I think that concern applies pretty much equally whichever way
you slice it. "Any exception other than an unknown from EL2 must imply
HVC" doesn't seem any less sketchy than "Any exception other than HVC
implies something is horribly wrong and abandoning EL2 might be wise"
to me, but it was primarily that the latter avoids having to faff with
the SPSR as well.

Actually, that's not a bad idea at all. Here's my take on the theme,
completely untested:

diff --git a/arch/arm64/kernel/hyp-stub.S b/arch/arm64/kernel/hyp-stub.S
index 43d212618834..5783dbab529f 100644
--- a/arch/arm64/kernel/hyp-stub.S
+++ b/arch/arm64/kernel/hyp-stub.S

@@ -46,6 +46,23 @@ SYM_CODE_END(__hyp_stub_vectors)
 	.align 11
 
 SYM_CODE_START_LOCAL(elx_sync)
+	// tpidr_el2 isn't used for anything while the stubs are
+	// installed, so use it to save x0 while we guess the
+	// exception type. No, we don't have a stack...
+	msr	tpidr_el2, x0
+	mrs	x0, esr_el2
+	ubfx	x0, x0, #26, #6
+	cmp	x0, #ESR_ELx_EC_HVC64
+	b.eq	elx_hvc
+	cbz	x0, elx_unknown
+
+	// For anything else, we have no reasonable way to handle
+	// the exception. Go back to the faulting instruction...
+	mrs	x0, tpidr_el2
+	eret
+
+elx_hvc:
+	mrs	x0, tpidr_el2
 	cmp	x0, #HVC_SET_VECTORS
 	b.ne	1f
 	msr	vbar_el2, x1

@@ -71,6 +88,14 @@ SYM_CODE_START_LOCAL(elx_sync)
 
 9:	mov	x0, xzr
 	eret
+
+elx_unknown:
+	// Assumes this was a HVC that went really wrong...
+	mrs	x0, elr_el2
+	add	x0, x0, #4
+	msr	elr_el2, x0
+	mov_q	x0, HVC_STUB_ERR
+	eret
 SYM_CODE_END(elx_sync)
 
 // nVHE? No way! Give me the real thing!

No big deal either way, just one of my "I reckon this could be
shorter..." musings; it's been particularly Friday today :)

Well, I just made it a lot longer! :D Let me know what you think.

Thanks,

	M.

-- 
Without deviation from the norm, progress is not possible.

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