LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Marc Zyngier <maz@kernel.org>
To: Robin Murphy <robin.murphy@arm.com>
Cc: linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org, "Rafał Miłecki" <zajec5@gmail.com>,
	"Will Deacon" <will@kernel.org>,
	"Catalin Marinas" <catalin.marinas@arm.com>,
	"Mark Rutland" <mark.rutland@arm.com>,
	"Ard Biesheuvel" <ardb@kernel.org>,
	"Florian Fainelli" <f.fainelli@gmail.com>,
	bcm-kernel-feedback-list@broadcom.com, kernel-team@android.com
Subject: Re: [PATCH 2/5] arm64: Handle UNDEF in the EL2 stub vectors
Date: Sat, 14 Aug 2021 10:38:30 +0100	[thread overview]
Message-ID: <87h7fs1i3t.wl-maz@kernel.org> (raw)
In-Reply-To: <060ef66a-6d6f-082e-5f69-117235b8ce4e@arm.com>

On Fri, 13 Aug 2021 19:17:56 +0100,
Robin Murphy <robin.murphy@arm.com> wrote:
> 
> On 2021-08-13 18:41, Marc Zyngier wrote:
> > On Fri, 13 Aug 2021 14:08:23 +0100,
> > Robin Murphy <robin.murphy@arm.com> wrote:
> >> 
> >> On 2021-08-12 20:02, Marc Zyngier wrote:
> >>> 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.

  reply	other threads:[~2021-08-14  9:38 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-08-12 19:02 [PATCH 0/5] arm64: Survival kit for SCR_EL3.HCE==0 conditions Marc Zyngier
2021-08-12 19:02 ` [PATCH 1/5] arm64: Directly expand __init_el2_nvhe_prepare_eret where needed Marc Zyngier
2021-08-12 19:02 ` [PATCH 2/5] arm64: Handle UNDEF in the EL2 stub vectors Marc Zyngier
2021-08-13 13:08   ` Robin Murphy
2021-08-13 17:41     ` Marc Zyngier
2021-08-13 18:17       ` Robin Murphy
2021-08-14  9:38         ` Marc Zyngier [this message]
2021-08-12 19:02 ` [PATCH 3/5] arm64: Detect disabled HVC early Marc Zyngier
2021-08-12 19:47   ` Rafał Miłecki
2021-08-13  9:05   ` Will Deacon
2021-08-13 17:33     ` Marc Zyngier
2021-08-12 19:02 ` [PATCH 4/5] arm64: Warn on booting at EL2 with HVC disabled Marc Zyngier
2021-08-12 19:58   ` Rafał Miłecki
2021-08-12 19:02 ` [PATCH 5/5] arm64: Document the requirement for SCR_EL3.HCE Marc Zyngier
2021-08-24 10:49   ` Catalin Marinas
2021-08-24 10:52     ` Mark Rutland
2021-08-15  7:28 ` [PATCH 0/5] arm64: Survival kit for SCR_EL3.HCE==0 conditions Florian Fainelli
2021-08-15  9:27   ` Marc Zyngier
2021-08-22 11:31     ` Florian Fainelli
2021-08-24 16:19 ` (subset) " Catalin Marinas

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=87h7fs1i3t.wl-maz@kernel.org \
    --to=maz@kernel.org \
    --cc=ardb@kernel.org \
    --cc=bcm-kernel-feedback-list@broadcom.com \
    --cc=catalin.marinas@arm.com \
    --cc=f.fainelli@gmail.com \
    --cc=kernel-team@android.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mark.rutland@arm.com \
    --cc=robin.murphy@arm.com \
    --cc=will@kernel.org \
    --cc=zajec5@gmail.com \
    --subject='Re: [PATCH 2/5] arm64: Handle UNDEF in the EL2 stub vectors' \
    /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

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