Re: [PATCH v1] KVM: arm64: selftests: Test pointer authentication support in KVM guest

[Marc Zyngier <maz@kernel.org>]

Hi Jing,

Thanks for getting the ball rolling on that front.

On Wed, 26 Jul 2023 05:46:51 +0100,
Jing Zhang <jingzhangos@google.com> wrote:
> 
> Add a selftest to verify the support for pointer authentication in KVM
> guest.

I guess it'd be worth describing *what* you are testing.

> 
> Signed-off-by: Jing Zhang <jingzhangos@google.com>
> ---
>  tools/testing/selftests/kvm/Makefile          |   1 +
>  .../selftests/kvm/aarch64/pauth_test.c        | 143 ++++++++++++++++++
>  .../selftests/kvm/include/aarch64/processor.h |   2 +
>  3 files changed, 146 insertions(+)
>  create mode 100644 tools/testing/selftests/kvm/aarch64/pauth_test.c
> 
> diff --git a/tools/testing/selftests/kvm/Makefile b/tools/testing/selftests/kvm/Makefile
> index c692cc86e7da..9bac5aecd66d 100644
> --- a/tools/testing/selftests/kvm/Makefile
> +++ b/tools/testing/selftests/kvm/Makefile
> @@ -143,6 +143,7 @@ TEST_GEN_PROGS_aarch64 += aarch64/debug-exceptions
>  TEST_GEN_PROGS_aarch64 += aarch64/get-reg-list
>  TEST_GEN_PROGS_aarch64 += aarch64/hypercalls
>  TEST_GEN_PROGS_aarch64 += aarch64/page_fault_test
> +TEST_GEN_PROGS_aarch64 += aarch64/pauth_test
>  TEST_GEN_PROGS_aarch64 += aarch64/psci_test
>  TEST_GEN_PROGS_aarch64 += aarch64/smccc_filter
>  TEST_GEN_PROGS_aarch64 += aarch64/vcpu_width_config
> diff --git a/tools/testing/selftests/kvm/aarch64/pauth_test.c b/tools/testing/selftests/kvm/aarch64/pauth_test.c
> new file mode 100644
> index 000000000000..d5f982da8891
> --- /dev/null
> +++ b/tools/testing/selftests/kvm/aarch64/pauth_test.c
> @@ -0,0 +1,143 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +/*
> + * pauth_test - Test for KVM guest pointer authentication.
> + *
> + * Copyright (c) 2023 Google LLC.
> + *
> + */
> +
> +#define _GNU_SOURCE
> +
> +#include <sched.h>
> +
> +#include "kvm_util.h"
> +#include "processor.h"
> +#include "test_util.h"
> +
> +enum uc_args {
> +	WAIT_MIGRATION,
> +	PASS,
> +	FAIL,
> +	FAIL_KVM,
> +	FAIL_INSTR,
> +};
> +
> +static noinline void pac_corruptor(void)
> +{
> +	__asm__ __volatile__(
> +		"paciasp\n"
> +		"eor lr, lr, #1 << 53\n"

Why bit 53? This looks pretty odd. Given that you don't compute the
size of the PAC field (think FEAT_D128...), this isn't a safe bet...

> +	);
> +
> +	/* Migrate guest to another physical CPU before authentication */
> +	GUEST_SYNC(WAIT_MIGRATION);
> +	__asm__ __volatile__("autiasp\n");

If the test was compiled with PAuth enabled, you shouldn't need to add
the paciasp/authiasp instructions. On the other hand, the whole
"corrupt LR" is extremely fragile -- the compiler doesn't know you've
messed with it, and it is free to reuse it.

If you want a reliable test, you must write this entirely in
assembly.

> +}
> +
> +static void guest_code(void)
> +{
> +	uint64_t sctlr = read_sysreg(sctlr_el1);
> +
> +	/* Enable PAuth */
> +	sctlr |= SCTLR_ELx_ENIA | SCTLR_ELx_ENIB | SCTLR_ELx_ENDA | SCTLR_ELx_ENDB;
> +	write_sysreg(sctlr, sctlr_el1);
> +	isb();

Out of curiosity, where are the keys set up? Because part of the
validation would be that for a given set of keys and authentication
algorithm, we obtain the same results.

> +
> +	pac_corruptor();
> +
> +	/* Shouldn't be here unless the pac_corruptor didn't do its work */
> +	GUEST_SYNC(FAIL);
> +	GUEST_DONE();
> +}
> +
> +/* Guest will get an unknown exception if KVM doesn't support guest PAuth */
> +static void guest_unknown_handler(struct ex_regs *regs)
> +{
> +	GUEST_SYNC(FAIL_KVM);
> +	GUEST_DONE();
> +}
> +
> +/* Guest will get a FPAC exception if KVM support guest PAuth */
> +static void guest_fpac_handler(struct ex_regs *regs)
> +{
> +	GUEST_SYNC(PASS);
> +	GUEST_DONE();
> +}
> +
> +/* Guest will get an instruction abort exception if the PAuth instructions have
> + * no effect (or PAuth not enabled in guest), which would cause guest to fetch
> + * an invalid instruction due to the corrupted LR.
> + */
> +static void guest_iabt_handler(struct ex_regs *regs)
> +{
> +	GUEST_SYNC(FAIL_INSTR);
> +	GUEST_DONE();
> +}
> +
> +int main(void)
> +{
> +	struct kvm_vcpu_init init;
> +	struct kvm_vcpu *vcpu;
> +	struct kvm_vm *vm;
> +	struct ucall uc;
> +	cpu_set_t cpu_mask;
> +
> +	TEST_REQUIRE(kvm_has_cap(KVM_CAP_ARM_PTRAUTH_ADDRESS));
> +	TEST_REQUIRE(kvm_has_cap(KVM_CAP_ARM_PTRAUTH_GENERIC));
> +
> +	vm = vm_create(1);
> +
> +	vm_ioctl(vm, KVM_ARM_PREFERRED_TARGET, &init);
> +	init.features[0] |= ((1 << KVM_ARM_VCPU_PTRAUTH_ADDRESS) |
> +			     (1 << KVM_ARM_VCPU_PTRAUTH_GENERIC));
> +
> +	vcpu = aarch64_vcpu_add(vm, 0, &init, guest_code);
> +
> +	vm_init_descriptor_tables(vm);
> +	vcpu_init_descriptor_tables(vcpu);
> +
> +	vm_install_sync_handler(vm, VECTOR_SYNC_CURRENT,
> +				ESR_EC_UNKNOWN, guest_unknown_handler);
> +	vm_install_sync_handler(vm, VECTOR_SYNC_CURRENT,
> +				ESR_EC_FPAC, guest_fpac_handler);
> +	vm_install_sync_handler(vm, VECTOR_SYNC_CURRENT,
> +				ESR_EC_IABT, guest_iabt_handler);
> +
> +	while (1) {
> +		vcpu_run(vcpu);
> +
> +		switch (get_ucall(vcpu, &uc)) {
> +		case UCALL_ABORT:
> +			REPORT_GUEST_ASSERT(uc);
> +			break;
> +		case UCALL_SYNC:
> +			switch (uc.args[1]) {
> +			case PASS:
> +				/* KVM guest PAuth works! */
> +				break;
> +			case WAIT_MIGRATION:
> +				sched_getaffinity(0, sizeof(cpu_mask), &cpu_mask);
> +				CPU_CLR(sched_getcpu(), &cpu_mask);
> +				sched_setaffinity(0, sizeof(cpu_mask), &cpu_mask);
> +				break;
> +			case FAIL:
> +				TEST_FAIL("Guest corruptor code doesn't work!\n");
> +				break;
> +			case FAIL_KVM:
> +				TEST_FAIL("KVM doesn't support guest PAuth!\n");

Why is that a hard failure? The vast majority of the HW out there
doesn't support PAuth...

> +				break;
> +			case FAIL_INSTR:
> +				TEST_FAIL("Guest PAuth instructions don't work!\n");
> +				break;
> +			}
> +			break;
> +		case UCALL_DONE:
> +			goto done;

Why a goto instead of a break?

> +		default:
> +			TEST_FAIL("Unexpected ucall: %lu", uc.cmd);
> +		}
> +	}
> +
> +done:
> +	kvm_vm_free(vm);
> +}
> diff --git a/tools/testing/selftests/kvm/include/aarch64/processor.h b/tools/testing/selftests/kvm/include/aarch64/processor.h
> index cb537253a6b9..f8d541af9c06 100644
> --- a/tools/testing/selftests/kvm/include/aarch64/processor.h
> +++ b/tools/testing/selftests/kvm/include/aarch64/processor.h
> @@ -104,7 +104,9 @@ enum {
>  #define ESR_EC_SHIFT		26
>  #define ESR_EC_MASK		(ESR_EC_NUM - 1)
>  
> +#define ESR_EC_UNKNOWN		0x00
>  #define ESR_EC_SVC64		0x15
> +#define ESR_EC_FPAC		0x1c
>  #define ESR_EC_IABT		0x21
>  #define ESR_EC_DABT		0x25
>  #define ESR_EC_HW_BP_CURRENT	0x31
> 

Although that's a good start, PAuth instructions that are in the NOP
space are not that interesting, because we already have tons of code
using it. What I'd really love to see is a test exercising some of the
non-NOP stuff, including use of the generic auth keys and the
PACGA/XPAC* instructions.

As I mentioned above, another thing I'd like to see is a set of
reference results for a given set of keys and architected algorithm
(QARMA3, QARMA5) so that we can compare between implementations
(excluding the IMPDEF implementations, of course).

Thanks,

	M.

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