Re: [PATCH 1/4] KVM: arm64: Enable Pointer Authentication at EL2 if available

From: Marc Zyngier <maz@kernel.org>
To: Mark Rutland <mark.rutland@arm.com>
Cc: kernel-team@android.com, linux-arm-kernel@lists.infradead.org,
	kvm@vger.kernel.org, kvmarm@lists.cs.columbia.edu
Subject: Re: [PATCH 1/4] KVM: arm64: Enable Pointer Authentication at EL2 if available
Date: Mon, 15 Jun 2020 11:55:53 +0100	[thread overview]
Message-ID: <c1ab609a8888d1c67b1946ebbf934dac@kernel.org> (raw)
In-Reply-To: <20200615100318.GA773@C02TD0UTHF1T.local>

On 2020-06-15 11:03, Mark Rutland wrote:
> On Mon, Jun 15, 2020 at 09:19:51AM +0100, Marc Zyngier wrote:
>> While initializing EL2, switch Pointer Authentication if detected
>> from EL1. We use the EL1-provided keys though.
> 
> Perhaps "enable address authentication", to avoid confusion with
> context-switch, and since generic authentication cannot be disabled
> locally at EL2.

Ah, fair enough.

>> 
>> Signed-off-by: Marc Zyngier <maz@kernel.org>
>> ---
>>  arch/arm64/kvm/hyp-init.S | 11 +++++++++++
>>  1 file changed, 11 insertions(+)
>> 
>> diff --git a/arch/arm64/kvm/hyp-init.S b/arch/arm64/kvm/hyp-init.S
>> index 6e6ed5581eed..81732177507d 100644
>> --- a/arch/arm64/kvm/hyp-init.S
>> +++ b/arch/arm64/kvm/hyp-init.S
>> @@ -104,6 +104,17 @@ alternative_else_nop_endif
>>  	 */
>>  	mov_q	x4, (SCTLR_EL2_RES1 | (SCTLR_ELx_FLAGS & ~SCTLR_ELx_A))
>>  CPU_BE(	orr	x4, x4, #SCTLR_ELx_EE)
>> +alternative_if ARM64_HAS_ADDRESS_AUTH_ARCH
>> +	b	1f
>> +alternative_else_nop_endif
>> +alternative_if_not ARM64_HAS_ADDRESS_AUTH_IMP_DEF
>> +	b	2f
>> +alternative_else_nop_endif
> 
> I see this is the same pattern we use in the kvm context switch, but I
> think we can use the ARM64_HAS_ADDRESS_AUTH cap instead (likewise in 
> the
> existing code).
> 
> AFAICT that won't permit mismatch given both 
> ARM64_HAS_ADDRESS_AUTH_ARCH
> and ARM64_HAS_ADDRESS_AUTH_IMP_DEF are dealt with as
> ARM64_CPUCAP_BOOT_CPU_FEATURE.

That'd be a nice cleanup, as the two back to back alternatives are a bit 
hard to read.

> 
>> +1:
>> +	orr	x4, x4, #(SCTLR_ELx_ENIA | SCTLR_ELx_ENIB)
>> +	orr	x4, x4, #SCTLR_ELx_ENDA
>> +	orr	x4, x4, #SCTLR_ELx_ENDB
> 
> Assuming we have a spare register, it would be nice if we could follow 
> the same
> pattern as in proc.S, where we do:
> 
> | ldr     x2, =SCTLR_ELx_ENIA | SCTLR_ELx_ENIB | \
> |              SCTLR_ELx_ENDA | SCTLR_ELx_ENDB
> | orr     x0, x0, x2
> 
> ... though we could/should use mov_q rather than a load literal, here 
> and in
> proc.S.

Looks like this code isn't in -rc1 anymore, replaced with a mov_q in 
__ptrauth_keys_init_cpu.

I'll switch to that in v2.

Thanks,

         M.
-- 
Jazz is not dead. It just smells funny...

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