linux-kernel - Re: [RFC V3 PATCH 5/6] selftests: kvm: x86: Execute VMs with private memory

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]

Message-ID: <CAGtprH_c+vhr8iBYYd7+BZtwzs_r6uFzxPyW1D3bHGhmHugcnA@mail.gmail.com>
Date:   Fri, 14 Oct 2022 15:05:22 +0530
From:   Vishal Annapurve <vannapurve@...gle.com>
To:     Sean Christopherson <seanjc@...gle.com>
Cc:     x86@...nel.org, kvm@...r.kernel.org, linux-kernel@...r.kernel.org,
        linux-kselftest@...r.kernel.org, pbonzini@...hat.com,
        vkuznets@...hat.com, wanpengli@...cent.com, jmattson@...gle.com,
        joro@...tes.org, tglx@...utronix.de, mingo@...hat.com,
        bp@...en8.de, dave.hansen@...ux.intel.com, hpa@...or.com,
        shuah@...nel.org, yang.zhong@...el.com, drjones@...hat.com,
        ricarkol@...gle.com, aaronlewis@...gle.com, wei.w.wang@...el.com,
        kirill.shutemov@...ux.intel.com, corbet@....net, hughd@...gle.com,
        jlayton@...nel.org, bfields@...ldses.org,
        akpm@...ux-foundation.org, chao.p.peng@...ux.intel.com,
        yu.c.zhang@...ux.intel.com, jun.nakajima@...el.com,
        dave.hansen@...el.com, michael.roth@....com, qperret@...gle.com,
        steven.price@....com, ak@...ux.intel.com, david@...hat.com,
        luto@...nel.org, vbabka@...e.cz, marcorr@...gle.com,
        erdemaktas@...gle.com, pgonda@...gle.com, nikunj@....com,
        diviness@...gle.com, maz@...nel.org, dmatlack@...gle.com,
        axelrasmussen@...gle.com, maciej.szmigiero@...cle.com,
        mizhang@...gle.com, bgardon@...gle.com
Subject: Re: [RFC V3 PATCH 5/6] selftests: kvm: x86: Execute VMs with private memory

On Fri, Oct 7, 2022 at 1:47 AM Sean Christopherson <seanjc@...gle.com> wrote:
>
> On Fri, Aug 19, 2022, Vishal Annapurve wrote:
> > +/*
> > + * Execute KVM hypercall to change memory access type for a given gpa range.
> > + *
> > + * Input Args:
> > + *   type - memory conversion type TO_SHARED/TO_PRIVATE
> > + *   gpa - starting gpa address
> > + *   size - size of the range starting from gpa for which memory access needs
> > + *     to be changed
> > + *
> > + * Output Args: None
> > + *
> > + * Return: None
> > + *
> > + * Function called by guest logic in selftests to update the memory access type
> > + * for a given gpa range. This API is useful in exercising implicit conversion
> > + * path.
> > + */
> > +void guest_update_mem_access(enum mem_conversion_type type, uint64_t gpa,
> > +     uint64_t size)
>
> Provide wrappers to self-document what's going on, then the massive block comments
> go away.  And the guts of this and guest_update_mem_map() are nearly identical.
>
> Hmm, and we probably want to make it possible to do negative testing.
>
> Then the one-off enums for TO_PRIVATE and whatnot go way too.
>
> > +{
> > +     int ret = kvm_hypercall(KVM_HC_MAP_GPA_RANGE, gpa, size >> MIN_PAGE_SHIFT,
>
> Needs an assert that @size is page aligned.  And since these are x86-64 specific,
> just use PAGE_SHIFT.  Huh, IS_ALIGNED() doesn't exist in selftests.  That should
> be added, either by pulling in align.h or by adding the generic macros to
> kvm_util_base.h.
>
> And then x86-64's processor.h can defined IS_PAGE_ALIGNED().
>
> E.g.
>
> static inline void __kvm_hypercall_map_gpa_range(uint64_t gpa, uint64_t size,
>                                                  uint64_t flags)
> {
>         return = kvm_hypercall(KVM_HC_MAP_GPA_RANGE, gpa, size >> PAGE_SHIFT, flags, 0);
> }
>
> static inline void kvm_hypercall_map_gpa_range(uint64_t gpa, uint64_t size,
>                                                uint64_t flags)
> {
>         int ret;
>
>         GUEST_ASSERT_2(IS_PAGE_ALIGNED(gpa) && IS_PAGE_ALIGNED(size), gpa, size);
>
>         ret = __kvm_hypercall_map_gpa_range(gpa, size, flags);
>         GUEST_ASSERT_1(!ret, ret);
> }
>
> static inline kvm_hypercall_map_shared(uint64_t gpa, uint64_t size)
> {
>         kvm_hypercall_map_gpa_range(gpa, size, KVM_CLR_GPA_RANGE_ENC_ACCESS);
> }
>
> static inline kvm_hypercall_map_private(uint64_t gpa, uint64_t size)
> {
>         kvm_hypercall_map_gpa_range(gpa, size, KVM_MARK_GPA_RANGE_ENC_ACCESS);
> }
>
> > +static void handle_vm_exit_map_gpa_hypercall(struct kvm_vm *vm,
> > +                             volatile struct kvm_run *run)
>
> Pass in @vcpu, not a vm+run.
>
> > +{
> > +     uint64_t gpa, npages, attrs, size;
> > +
> > +     TEST_ASSERT(run->hypercall.nr == KVM_HC_MAP_GPA_RANGE,
> > +             "Unhandled Hypercall %lld\n", run->hypercall.nr);
> > +     gpa = run->hypercall.args[0];
> > +     npages = run->hypercall.args[1];
> > +     size = npages << MIN_PAGE_SHIFT;
> > +     attrs = run->hypercall.args[2];
> > +     pr_info("Explicit conversion off 0x%lx size 0x%lx to %s\n", gpa, size,
> > +             (attrs & KVM_MAP_GPA_RANGE_ENCRYPTED) ? "private" : "shared");
> > +
> > +     if (attrs & KVM_MAP_GPA_RANGE_ENCRYPTED)
> > +             vm_update_private_mem(vm, gpa, size, ALLOCATE_MEM);
> > +     else
> > +             vm_update_private_mem(vm, gpa, size, UNBACK_MEM);
> > +
> > +     run->hypercall.ret = 0;
> > +}
> > +
> > +static void handle_vm_exit_memory_error(struct kvm_vm *vm, volatile struct kvm_run *run)
>
> Same  here, take a @vcpu.

Ack. Will address these comments in the next series.