linux-kernel - Re: [RFC] KVM: x86: Support KVM VMs sharing SEV context

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]

Date:   Wed, 24 Feb 2021 08:58:29 -0800
From:   Sean Christopherson <seanjc@...gle.com>
To:     Paolo Bonzini <pbonzini@...hat.com>
Cc:     Nathan Tempelman <natet@...gle.com>, thomas.lendacky@....com,
        x86@...nel.org, kvm@...r.kernel.org, linux-kernel@...r.kernel.org,
        srutherford@...gle.com, rientjes@...gle.com, brijesh.singh@....com,
        Ashish.Kalra@....com, Nathaniel McCallum <npmccallum@...hat.com>,
        Marc Orr <marcorr@...gle.com>,
        "Hyunwook (Wooky) Baek" <baekhw@...gle.com>
Subject: Re: [RFC] KVM: x86: Support KVM VMs sharing SEV context

+Marc and Wooky

On Wed, Feb 24, 2021, Paolo Bonzini wrote:
> [CCing Nathaniel McCallum]

Ah, I assume Enarx can use this to share an asid across multiple workloads?
 
> On 24/02/21 09:59, Nathan Tempelman wrote:
> > 
> > +7.23 KVM_CAP_VM_COPY_ENC_CONTEXT_TO
> > +-----------------------------------
> > +
> > +Architectures: x86 SEV enabled
> > +Type: system
> 
> vm ioctl, not system (/dev/kvm).  But, see below.
> 
> > +Parameters: args[0] is the fd of the kvm to mirror encryption context to
> > +Returns: 0 on success; ENOTTY on error
> > +
> > +This capability enables userspace to copy encryption context from a primary
> > +vm to the vm indicated by the fd.
> > +
> > +This is intended to support in-guest workloads scheduled by the host. This
> > +allows the in-guest workload to maintain its own NPTs and keeps the two vms
> > +from accidentally clobbering each other with interrupts and the like (separate
> > +APIC/MSRs/etc).
> 
> From purely an API design standpoint, I think I'd prefer a "set context
> from" API (the other way round) to match the existing KVM_SEV_INIT.
> 
> Apart from this, the code is very nice and I would have no issues merging
> this in 5.12 even after the merge window.

And I don't think it would prevent us from refcounting the asid itself in the
future, e.g. to avoid pinning the "parent" KVM, which was my biggest hesitation
with the approach.

That being said, is there a strong need to get this into 5.12?  AIUI, this hasn't
had any meaningful testing, selftests/kvm-unit-tests or otherwise.  Pushing out
to 5.13 might give us a good chance of getting some real testing before merging,
depending on the readiness of SEV testing support.

> As an aside, do you happen to have SEV selftests at Google?  I would gladly
> volunteer to write the selftest myself for this ioctl given the
> infrastructure.

No, but I believe someone(s) from AMD is working on selftests.

On a related topic, Marc and Wooky are working on adapting kvm-unit-tests to run
SEV guests.  IIUC, the last open before posting an RFC is how best to make
kvm-unit-tests play nice with UEFI.