lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <87im091bu7.wl-maz@kernel.org>
Date:   Fri, 13 Aug 2021 18:41:36 +0100
From:   Marc Zyngier <maz@...nel.org>
To:     Robin Murphy <robin.murphy@....com>
Cc:     linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
        Rafał Miłecki <zajec5@...il.com>,
        Will Deacon <will@...nel.org>,
        Catalin Marinas <catalin.marinas@....com>,
        Mark Rutland <mark.rutland@....com>,
        Ard Biesheuvel <ardb@...nel.org>,
        Florian Fainelli <f.fainelli@...il.com>,
        bcm-kernel-feedback-list@...adcom.com, kernel-team@...roid.com
Subject: Re: [PATCH 2/5] arm64: Handle UNDEF in the EL2 stub vectors

On Fri, 13 Aug 2021 14:08:23 +0100,
Robin Murphy <robin.murphy@....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@...nel.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).

Thanks,

	M.

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ