Open Stack

Hi Jesse,


2018-06-19 18:57 GMT+01:00 Larrew, Jesse <Jesse.Larrew at amd.com>:

> Hi Eric,
>
>
>
> We’re still working on setting up the CI server, but we’ve decided to make
> the SEV patches available on our github repo so folks can kick the tires,
> so to speak.
>
\o/ - great!


>
>
> The SEV patches require a new dependency in the vendor tree and updates a
> few others:
>
>    1. intel-go/cpuid (new dependency),
>    2. intel/govmm,
>    3. virtcontainers
>
>
>
> To submit a PR to kata-runtime, should I first fork each of the above
> projects and submit PRs against them, then point to those PRs when I submit
> to kata? This is the first Go project that I’ve contributed to, so I’m not
> sure what the protocol is. Any tips would be helpful. Thanks!
>
For (1) and (2), yes, you'll need to click "fork" on
https://github.com/intel-go/cpuid and https://github.com/intel/govmm, and
then raise PRs on those two projects.

Once both those PRs have landed, since virtcontainers is now part of the
Kata runtime you can then raise a PR on
https://github.com/kata-containers/runtime for the changes you need to make
to https://github.com/kata-containers/runtime/tree/master/virtcontainers.

As part of that change, you'll need to update the runtime vendoring to pull
in (1) and (2):

- Add "github.com/intel-go/cpuid" to Gopkg.toml to pull in your upstream
changes.

  See
https://github.com/kata-containers/community/blob/master/VENDORING.md#vendor-a-newly-imported-package

- Update the commit for "github.com/intel/govmm" in Gopkg.toml to pull in
your upstream changes.

  See
https://github.com/kata-containers/community/blob/master/VENDORING.md#update-a-vendored-package

Note that you can *probably* get away with updating the Gopkg.toml file
once for both changes (meaning you only need to run "dep ensure" once) and
having all the changes on a single commit.

HTH.

Cheers,

James


>
> Sincerely,
>
> Jesse
>
>
>
> *From:* Ernst, Eric [mailto:eric.ernst at intel.com]
> *Sent:* Wednesday, May 9, 2018 3:45 PM
>
> *To:* Larrew, Jesse <Jesse.Larrew at amd.com>
> *Cc:* Jon Olson <jonolson at google.com>; Singh, Brijesh <
> brijesh.singh at amd.com>; Kaplan, David <David.Kaplan at amd.com>;
> Hollingsworth, Brent <brent.hollingsworth at amd.com>;
> kata-dev at lists.katacontainers.io; Woller, Thomas <thomas.woller at amd.com>
> *Subject:* Re: [kata-dev] Kata with AMD Secure Encrypted Virtualization
> (SEV)
>
>
>
> Hey Jesse,
>
>
>
> I had the chance to meet Brent @ Red Hat Summit yesterday, and this was a
> good reminder to reach out regarding SEV support in Kata.
>
>
>
> First, as expressed to Brent, this is a sweet use case.
>
>
>
> Second, one of the things that has come to mind for me is how we can
> verify.
>
>
>
> Our CI is running on a mix of baremetal machines for metrics and machines
> in the cloud (via Azure) for functional testing.  For other architectures,
> and including this feature, it’d be best to have this exercised in CI.
> Basically, I’d want to make sure we can replicate the CI on a single AMD
> Epyc (or other SEV enabled system) which could help gate our CI process.
> We have the test setup designed to be easily reproduced, and can work
> together on getting this setup, assuming we find a machine which  this can
> run on.
>
>
>
> With this feature enabled in our CI, we’d be able to guarantee that it
> continues to work (and if it fails, it should be an easy fix).
>
>
>
> Thanks,
> Eric
>
>
>
>
>
> *From: *"Larrew, Jesse" <Jesse.Larrew at amd.com>
> *Date: *Tuesday, May 1, 2018 at 10:28 AM
> *To: *Eric Ernst <eric.ernst at intel.com>
> *Cc: *Jon Olson <jonolson at google.com>, "Singh, Brijesh" <
> brijesh.singh at amd.com>, "Kaplan, David" <David.Kaplan at amd.com>,
> "Hollingsworth, Brent" <brent.hollingsworth at amd.com>, "kata-dev at lists.
> katacontainers.io" <kata-dev at lists.katacontainers.io>, "Woller, Thomas" <
> thomas.woller at amd.com>
> *Subject: *RE: [kata-dev] Kata with AMD Secure Encrypted Virtualization
> (SEV)
>
>
>
> Hi Eric,
>
>
>
> I got SEV working with the latest 0.0.1 kata runtime. Is there still a
> chance of getting this in before the 1.0 release on the 22nd? Or are we
> looking at 1.1.0 at this point?
>
>
>
> Sincerely,
>
> Jesse
>
>
>
> *From:* Ernst, Eric [mailto:eric.ernst at intel.com <eric.ernst at intel.com>]
> *Sent:* Saturday, April 7, 2018 9:18 PM
> *To:* Larrew, Jesse <Jesse.Larrew at amd.com>
> *Cc:* Jon Olson <jonolson at google.com>; Singh, Brijesh <
> brijesh.singh at amd.com>; Kaplan, David <David.Kaplan at amd.com>;
> Hollingsworth, Brent <brent.hollingsworth at amd.com>;
> kata-dev at lists.katacontainers.io; Woller, Thomas <thomas.woller at amd.com>
> *Subject:* Re: [kata-dev] Kata with AMD Secure Encrypted Virtualization
> (SEV)
>
>
>
> There isn’t really a deadline. While we are still discussing release
> cadence for Kata, this seems like a nice feature to get in, perhaps after
> our initial 1.0 release (targeting ~June 1).
>
>
>
> Eric
>
>
> On Apr 7, 2018, at 6:22 PM, Larrew, Jesse <Jesse.Larrew at amd.com> wrote:
>
> Hi Eric,
>
>
>
> I’m seeking internal approval to contribute. Do you have a deadline for a
> decision?
>
>
>
> Sincerely,
>
> Jesse
>
>
>
> *From:* Ernst, Eric [mailto:eric.ernst at intel.com <eric.ernst at intel.com>]
> *Sent:* Friday, April 6, 2018 2:08 PM
> *To:* Larrew, Jesse <Jesse.Larrew at amd.com>; Jon Olson <jonolson at google.com
> >
> *Cc:* Singh, Brijesh <brijesh.singh at amd.com>; Kaplan, David <
> David.Kaplan at amd.com>; Hollingsworth, Brent <brent.hollingsworth at amd.com>;
> kata-dev at lists.katacontainers.io; Woller, Thomas <thomas.woller at amd.com>
> *Subject:* Re: [kata-dev] Kata with AMD Secure Encrypted Virtualization
> (SEV)
>
>
>
> Jesse,
>
>
>
> I wanted to follow up here… I think this is a pretty exciting feature and
> I wanted to see what next steps are. Is this something that you’re planning
> to or can start contributing to the Kata project?
>
>
>
> Thanks
> Eric
>
>
>
> *From: *"Larrew, Jesse" <Jesse.Larrew at amd.com>
> *Date: *Friday, February 23, 2018 at 7:11 PM
> *To: *Jon Olson <jonolson at google.com>
> *Cc: *"Singh, Brijesh" <brijesh.singh at amd.com>, "Kaplan, David" <
> David.Kaplan at amd.com>, "Hollingsworth, Brent" <brent.hollingsworth at amd.com>,
> "kata-dev at lists.katacontainers.io" <kata-dev at lists.katacontainers.io>,
> "Woller, Thomas" <thomas.woller at amd.com>
> *Subject: *Re: [kata-dev] Kata with AMD Secure Encrypted Virtualization
> (SEV)
>
>
>
> *From:* Jon Olson [mailto:jonolson at google.com <jonolson at google.com>]
> *Sent:* Friday, February 23, 2018 6:58 PM
> *To:* Larrew, Jesse <Jesse.Larrew at amd.com>
> *Cc:* Castelino, Manohar R <manohar.r.castelino at intel.com>; Samuel Ortiz <
> sameo at linux.intel.com>; Hollingsworth, Brent <brent.hollingsworth at amd.com>;
> kata-dev at lists.katacontainers.io; Singh, Brijesh <brijesh.singh at amd.com>;
> Kaplan, David <David.Kaplan at amd.com>; Woller, Thomas <
> thomas.woller at amd.com>
> *Subject:* Re: [kata-dev] Kata with AMD Secure Encrypted Virtualization
> (SEV)
>
>
>
>
>
> On Fri, Feb 23, 2018 at 4:42 PM Larrew, Jesse <Jesse.Larrew at amd.com>
> wrote:
>
> > From: Castelino, Manohar R [mailto:manohar.r.castelino at intel.com]
> > Sent: Friday, February 23, 2018 3:53 PM
> > To: Larrew, Jesse <Jesse.Larrew at amd.com>; Samuel Ortiz
> > <sameo at linux.intel.com>
> > Cc: Hollingsworth, Brent <brent.hollingsworth at amd.com>; Woller, Thomas
> > <thomas.woller at amd.com>; Kaplan, David <David.Kaplan at amd.com>; kata-
> > dev at lists.katacontainers.io
> > Subject: RE: [kata-dev] Kata with AMD Secure Encrypted Virtualization
> (SEV)
> >
> > Jesse,
> >
> > > On EPYC, our IOMMU doesn't yet support SEV, so DMA to/from devices
> > needs
> > > to be done using unencrypted pages. It was easy to implement this using
> > the
> > > bounce buffers provided by SWIOTLB. As you guessed, a quick change to
> > > vring_use_dma_api() got virtio support working properly:
> >
> > Clear Containers today supports direct device assignment via SRIOV.
> > This requires pre-allocation and pinning of VM memory.
> > Will this continue to work?
> >
> > Also we have been working on reverse ballooning. i.e. free unused memory
> > from the VM back to the host. Is there is a way to get this to work with
> > encrypted memory
> >
> > For more details about the patches
> > https://gist.github.com/sboeuf/fc71f0218a81997251ee0d7668df2bd9
> >
> > -manohar
> >
> >
>
> Hi Manohar,
>
> SEV also requires the guest memory to be pre-allocated and pinned [1], so
> that's not a problem. As long as the PF drivers in the guest are using the
> dma apis, everything should continue to work.
>
>
>
> That's surprising -- I can see where reclaim would be challenging without
> something like a balloon, but why must the be initially backed? What
> happens if you leave a page unbacked and attempt to lazily back it on an
> EPT fault?
>
>
>
> *[JDL] You’re right Jon. I misspoke above. The memory only needs to be
> pinned; the backing pages can be faulted in on demand. Sorry for the
> confusion.*
>
>
>
>
> Similarly, the reverse ballooning patches should also work with SEV. In
> fact, I would argue that SEV compliments this feature by ensuring that
> physical page contents aren't exposed to the host when the guest uses
> MADV_FREE. I've CC'ed our KVM expert, Brijesh Singh, just in case he sees
> something that I missed.
>
> Sincerely,
> Jesse
>
> [1] In order to ensure that memory blocks with identical data will encrypt
> to different ciphertext, SEV mixes the physical address into the encryption
> algorithm. As a result, if a page of memory is moved to a different
> physical address, it will not decrypt properly. This also defeats
> block-move attacks on the guest memory, but it also requires all guest
> memory to be pinned.
>
>
>
> _______________________________________________
> kata-dev mailing list
> kata-dev at lists.katacontainers.io
> http://lists.katacontainers.io/cgi-bin/mailman/listinfo/kata-dev
>
>


-- 
James
---
https://katacontainers.io/ | https://github.com/kata-containers
<https://github.com/clearcontainers>
Open Source Technology Center
Intel Corporation (UK) Ltd. - Co. Reg. #1134945 - Pipers Way, Swindon SN3
1RJ.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.katacontainers.io/pipermail/kata-dev/attachments/20180620/e0bd50e5/attachment-0001.html>