linux-kernel - Re: [RFC V1 PATCH 0/5] selftests: KVM: selftests for fd-based approach of supporting 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: <20220412082500.GA7309@chaop.bj.intel.com>
Date:   Tue, 12 Apr 2022 16:25:00 +0800
From:   Chao Peng <chao.p.peng@...ux.intel.com>
To:     "Nikunj A. Dadhania" <nikunj@....com>
Cc:     Vishal Annapurve <vannapurve@...gle.com>, 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,
        shauh@...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, 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, seanjc@...gle.com, diviness@...gle.com
Subject: Re: [RFC V1 PATCH 0/5] selftests: KVM: selftests for fd-based
 approach of supporting private memory

On Mon, Apr 11, 2022 at 05:31:09PM +0530, Nikunj A. Dadhania wrote:
> On 4/9/2022 2:35 AM, Vishal Annapurve wrote:
> > This series implements selftests targeting the feature floated by Chao
> > via:
> > https://lore.kernel.org/linux-mm/20220310140911.50924-1-chao.p.peng@linux.intel.com/
> > 
> 
> Thanks for working on this.
> 
> > 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.
> > 
> > Confidential platforms along with the confidentiality aware software
> > stack support a notion of private/shared accesses from the confidential
> > VMs.
> > Generally, a bit in the GPA conveys the shared/private-ness of the
> > access. Non-confidential platforms don't have a notion of private or
> > shared accesses from the guest VMs. To support this notion,
> > KVM_HC_MAP_GPA_RANGE
> > is modified to allow marking an access from a VM within a GPA range as
> > always shared or private. Any suggestions regarding implementing this ioctl
> > alternatively/cleanly are appreciated.
> > 
> > priv_memfd_test.c file adds a suite of two basic selftests to access private
> > memory from the guest via private/shared access and checking if the contents
> > can be leaked to/accessed by vmm via shared memory view.
> > 
> > Test results:
> > 1) PMPAT - PrivateMemoryPrivateAccess test passes
> > 2) PMSAT - PrivateMemorySharedAccess test fails currently and needs more
> > analysis to understand the reason of failure.
> 
> That could be because of the return code (*r = -1) from the KVM_EXIT_MEMORY_ERROR. 
> This gets interpreted as -EPERM in the VMM when the vcpu_run exits.
> 
> 	+	vcpu->run->exit_reason = KVM_EXIT_MEMORY_ERROR;
> 	+	vcpu->run->memory.flags = flags;
> 	+	vcpu->run->memory.padding = 0;
> 	+	vcpu->run->memory.gpa = fault->gfn << PAGE_SHIFT;
> 	+	vcpu->run->memory.size = PAGE_SIZE;
> 	+	fault->pfn = -1;
> 	+	*r = -1;
> 	+	return true;

That's true. The current private mem patch treats KVM_EXIT_MEMORY_ERROR as error
for KVM_RUN. That behavior needs to be discussed, but right now (v5) it hits the
ASSERT in tools/testing/selftests/kvm/lib/kvm_util.c before you have chance to
handle KVM_EXIT_MEMORY_ERROR in this patch series.

void vcpu_run(struct kvm_vm *vm, uint32_t vcpuid)
{
        int ret = _vcpu_run(vm, vcpuid);
        TEST_ASSERT(ret == 0, "KVM_RUN IOCTL failed, "
                "rc: %i errno: %i", ret, errno);
}

Thanks,
Chao

> 
> 
> Regards
> Nikunj
> 
> [1] https://lore.kernel.org/all/20220310140911.50924-10-chao.p.peng@linux.intel.com/#t