Open Stack

This issue only occurs if you do *not* build the runtime in $GOPATH/src/
github.com/kata-containers/runtime. Hence, build if there if you can :)

See: https://github.com/kata-containers/runtime/issues/430

Cheers,

James

2018-06-20 10:04 GMT+01:00 Whaley, Graham <graham.whaley at intel.com>:

> Hi Jesse,
>
> The normal workflow for submitting PRs to the kata repos is pretty much
> the standard github way – you fork the report, make yourself a branch in
> your fork, do the work there, and push to your fork on github. The github
> website will then show you a ‘make pull request’ dialog box on both (iirc)
> your or the main repo home page, and you submit via that (well, that is
> what I do ;-).
>
>
>
> *Apart* from…. The runtime repo. There is a golang path dependency in the
> virtcontainers subdir, which means you cannot build it inside your own fork
> L. So the workflow there is (and others please correct me if you have a
> better way)
>
> -        Clone the main repo
>
> -        Make a branch in the main repo (on your local machine)
>
> -        Work within that branch
>
> -        Fork the main repo
>
> -        Add your fork as a remote to your main repo clone
>
> -        Push your working branch to **your** forked repo (and definitely
> not back to the main repo ;-)
>
> -        And then follow the PR submit process above.
>
>
>
> I ran into this yesterday ;-), and thought we had documented it – but, I
> could not find it in either the kata or CC repos. I somebody knows if we do
> have that documented, shout! Or, I’ll see if I can add it (but, tbh, it
> won’t be this week, and then I think it will fall off my radar! I guess
> I’ll go open an Issue right now at least…)
>
>
>
> Graham
>
>
>
> *From:* Larrew, Jesse [mailto:Jesse.Larrew at amd.com]
> *Sent:* Tuesday, June 19, 2018 6:57 PM
> *To:* Ernst, Eric <eric.ernst at intel.com>
> *Cc:* Singh, Brijesh <brijesh.singh at amd.com>; Kaplan, David <
> David.Kaplan at amd.com>; Hollingsworth, Brent <brent.hollingsworth at amd.com>;
> Woller, Thomas <thomas.woller at amd.com>; kata-dev at lists.katacontainers.io
>
> *Subject:* Re: [kata-dev] Kata with AMD Secure Encrypted Virtualization
> (SEV)
>
>
>
> 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.
>
>
>
> 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!
>
>
>
> Sincerely,
>
> Jesse
>
>
>
> *From:* Ernst, Eric [mailto:eric.ernst at intel.com <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.
>
> ---------------------------------------------------------------------
> Intel Corporation (UK) Limited
> Registered No. 1134945 (England)
> Registered Office: Pipers Way, Swindon SN3 1RJ
> VAT No: 860 2173 47
>
> This e-mail and any attachments may contain confidential material for
> the sole use of the intended recipient(s). Any review or distribution
> by others is strictly prohibited. If you are not the intended
> recipient, please contact the sender and delete all copies.
>
> _______________________________________________
> 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/b139c3e8/attachment-0001.html>