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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Marc,

On Wed, Jul 26, 2023 at 12:01 AM Marc Zyngier <maz@xxxxxxxxxx> wrote:
>
> Hi Jing,
>
> Thanks for getting the ball rolling on that front.
>
> On Wed, 26 Jul 2023 05:46:51 +0100,
> Jing Zhang <jingzhangos@xxxxxxxxxx> 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.
Sure, I will add test details.
>
> >
> > Signed-off-by: Jing Zhang <jingzhangos@xxxxxxxxxx>
> > ---
> >  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...
>
It is kind of arbitrarily chosen, but surely belongs to PAC since the
VM was created with mode VM_MODE_P40V48_4K by default. I will change
the VM creation call to explicitly specify the mode.
> > +     );
> > +
> > +     /* 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.
Right. I didn't take care of the LR when I added the GUEST_SYNC call.
I guess it would work too if I save the LR on stack before the call to
GUEST_SYNC and restore it later before the authentication instruction.
>
> > +}
> > +
> > +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.
I just used whatever in the key system registers. I will set up the
keys explicitly with given values. This then can also verify that KVM
saves/restores the keys correctly.
>
> > +
> > +     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...
Since previous TEST_REQUIRES have passed, KVM should be able to
support guest PAuth. The test will be skipped on those HW without
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?
To jump out of the while(1) loop.
>
> > +             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.
Sure, I will add more tests for non-NOP stuff.
>
> 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).
Sure. Will do.
>
> Thanks,
>
>         M.
>
> --
> Without deviation from the norm, progress is not possible.

Thanks,
Jing




[Index of Archives]     [KVM ARM]     [KVM ia64]     [KVM ppc]     [Virtualization Tools]     [Spice Development]     [Libvirt]     [Libvirt Users]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite Questions]     [Linux Kernel]     [Linux SCSI]     [XFree86]

  Powered by Linux