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

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: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Fri, 13 Aug 2021 14:08:23 +0100
From:   Robin Murphy <robin.murphy@....com>
To:     Marc Zyngier <maz@...nel.org>,
        linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org
Cc:     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 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?

Robin.

> +
> +0:	cmp	x0, #HVC_SET_VECTORS
>   	b.ne	1f
>   	msr	vbar_el2, x1
>   	b	9f
> @@ -71,6 +80,14 @@ SYM_CODE_START_LOCAL(elx_sync)
>   
>   9:	mov	x0, xzr
>   	eret
> +
> +el2_undef:
> +	// 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!
>