Message-ID: <CAGtprH_hsLPDzFREbSehsxQRj7piVC75xPXD7OsKLUULWiS1fw@mail.gmail.com>
Date:   Tue, 17 Jan 2023 19:11:22 -0800
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, 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, ackerleytng@...gle.com
Subject: Re: [V2 PATCH 0/6] KVM: selftests: selftests for fd-based private memory

On Tue, Jan 17, 2023 at 5:09 PM Sean Christopherson <seanjc@...gle.com> wrote:
>
> On Mon, Dec 05, 2022, Vishal Annapurve wrote:
> > This series implements selftests targeting the feature floated by Chao via:
> > https://lore.kernel.org/lkml/20221202061347.1070246-10-chao.p.peng@linux.intel.com/T/
> >
> > Below changes aim to test the fd based approach for guest private memory
> > in context of normal (non-confidential) VMs executing on non-confidential
> > platforms.
> >
> > private_mem_test.c file adds selftest to access private memory from the
> > guest via private/shared accesses and checking if the contents can be
> > leaked to/accessed by vmm via shared memory view before/after conversions.
> >
> > Updates in V2:
> > 1) Simplified vcpu run loop implementation API
> > 2) Removed VM creation logic from private mem library
>
> I pushed a rework version of this series to:
>
>   git@...hub.com:sean-jc/linux.git x86/upm_base_support
>

Thanks for the review and spending time to rework this series. The
revised version [1] looks cleaner and lighter.

> Can you take a look and make sure that I didn't completely botch anything, and
> preserved the spirit of what you are testing?
>

Yeah, the reworked selftest structure [1] looks good to me in general.
Few test cases that are missing in the reworked version:
* Checking if contents of GPA ranges corresponding to private memory
are not leaked to host userspace when accessing guest memory using HVA
ranges
* Checking if private to shared conversion of memory affects nearby
private pages.

> Going forward, no need to send a v3 at this time.  Whoever sends v11 of the series
> will be responsible for including tests.
>

Sounds good to me.

> No need to respond to comments either, unless of course there's something you
> object to, want to clarify, etc., in which case definitely pipe up.
>
> Beyond the SEV series, do you have additional UPM testcases written?  If so, can
> you post them, even if they're in a less-than-perfect state?  If they're in a
> "too embarassing to post" state, feel from to send them off list :-)
>

Ackerley (ackerleytng@...gle.com) is working on publishing the rfc v3
version of TDX selftests that include UPM specific selftests. He plans
to publish them this week.

> Last question, do you have a list of testcases that you consider "required" for
> UPM?  My off-the-cuff list of selftests I want to have before merging UPM is pretty
> short at this point:
>
>   - Negative testing of the memslot changes, e.g. bad alignment, bad fd,
>     illegal memslot updates, etc.
>   - Negative testing of restrictedmem, e.g. various combinations of overlapping
>     bindings of a single restrictedmem instance.
>   - Access vs. conversion stress, e.g. accessing a region in the guest while it's
>     concurrently converted by the host, maybe with fancy guest code to try and
>     detect TLB or ordering bugs?

List of testcases that I was tracking (covered by the current
selftests) as required:
1) Ensure private memory contents are not accessible to host userspace
using the HVA
2) Ensure shared memory contents are visible/accessible from both host
userspace and the guest
3) Ensure 1 and 2 holds across explicit memory conversions
4) Exercise memory conversions with mixed shared/private memory pages
in a huge page to catch issues like [2]
5) Ensure that explicit memory conversions don't affect nearby GPA ranges

Test Cases that will be covered by TDX/SNP selftests (in addition to
above scenarios):
6) Ensure 1 and 2 holds across implicit memory conversions
7) Ensure that implicit memory conversions don't affect nearby GPA ranges

Additional testcases possible:
8) Running conversion tests for non-overlapping GPA ranges of
same/different memslots from multiple vcpus

[1] - https://github.com/sean-jc/linux/commit/7e536bf3c45c623425bc84e8a96634efc3a619ed
[2] - https://lore.kernel.org/linux-mm/CAGtprH82H_fjtRbL0KUxOkgOk4pgbaEbAydDYfZ0qxz41JCnAQ@mail.gmail.com/

Powered by blists - more mailing lists