<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Feb 23, 2018 at 1:09 PM, Larrew, Jesse <span dir="ltr"><<a href="mailto:Jesse.Larrew@amd.com" target="_blank">Jesse.Larrew@amd.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div lang="EN-US" link="blue" vlink="purple">
<div class="m_4066686932561311945WordSection1">
<div style="border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in 4.0pt">
<div>
<div style="border:none;border-top:solid #e1e1e1 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b>From:</b> Ricardo Aravena [mailto:<a href="mailto:raravena80@gmail.com" target="_blank">raravena80@gmail.com</a>] <br>
<b>Sent:</b> Friday, February 23, 2018 10:32 AM<br>
<b>To:</b> Tao Peng <bergwolf@hyper.sh><br>
<b>Cc:</b> Larrew, Jesse <<a href="mailto:Jesse.Larrew@amd.com" target="_blank">Jesse.Larrew@amd.com</a>>; Hollingsworth, Brent <<a href="mailto:brent.hollingsworth@amd.com" target="_blank">brent.hollingsworth@amd.com</a>>; Woller, Thomas <<a href="mailto:thomas.woller@amd.com" target="_blank">thomas.woller@amd.com</a>>; Kaplan, David <<a href="mailto:David.Kaplan@amd.com" target="_blank">David.Kaplan@amd.com</a>>; <a href="mailto:kata-dev@lists.katacontainers.io" target="_blank">kata-dev@lists.katacontainers.<wbr>io</a><span class=""><br>
<b>Subject:</b> Re: [kata-dev] Kata with AMD Secure Encrypted Virtualization (SEV)<u></u><u></u></span></p>
</div>
</div>
<p class="MsoNormal"><u></u> <u></u></p>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
<div>
<p class="MsoNormal">On Fri, Feb 23, 2018 at 5:55 AM, Tao Peng <<a href="mailto:bergwolf@hyper.sh" target="_blank">bergwolf@hyper.sh</a>> wrote:<u></u><u></u></p><span class="">
<blockquote style="border:none;border-left:solid #cccccc 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in">
<p class="MsoNormal">On Fri, Feb 23, 2018 at 12:32 AM, Larrew, Jesse <<a href="mailto:Jesse.Larrew@amd.com" target="_blank">Jesse.Larrew@amd.com</a>> wrote:<br>
> Ah! Yes, live migration of encrypted guests is supported by the hardware. Qemu support is still being actively developed though. The details of migrating encrypted VMs are discussed in our Secure Encrypted Virtualization API [1]. Basically, the AMD Secure
Processor re-encrypts and integrity-protects the guest memory into discrete "packets" that can be sent to the destination machine. The transport/integrity keys used for migration are ephemeral keys negotiated with the receiving machine using a Diffie-Hellman
exchange.<br>
><br>
> Live migration is useful for VMs that need to be stateful. However, my impression of container use cases is that they are encouraged to be stateless. For stateless containers, it would most likely be quicker to simply throw away the container and start a
new one on the destination machine. Do you have specific use cases that require the ability to migrate containers?<br>
><br>
Yes. We have an optimization [1] based on the qemu live migration<br>
feature which let us share the initial part of guest memory among<br>
guests on the same host. It's a quite useful feature for vm-based<br>
container workload because the kernel and initramfs are most likely<br>
the same for all guests on the host.<u></u><u></u></p>
</blockquote>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">My two cents here:<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">It's also quite useful at a higher level when you are dealing with stateful services, that are not heavily containerized in prod yet. First ones that pop in my head are redis/memchached. Then there's also big data stateful type of dbs that
require a lot memory, say Cassandra, or Scylla. <u></u><u></u></p>
</div>
</span><div>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">That’s good information. Thanks! I’m definitely trying to understand which workloads would benefit most from the container-in-a-VM approach, and which features/capabilities are most important.<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">Are there any other features/tricks that an SEV implementation would need to preserve?</p></div></div></div></div></div></div></div></blockquote><div><br></div><div><br></div><div>You're welcome!</div><div><br></div><div>How about live migration recovery for disaster recovery (DR) type of scenarios? If for some reason somebody or something pulls the plug on either the server migrating from or the server migrating to, in the middle of it all. It would be nice if the data wouldn't get corrupted. </div><div><br></div><div>There's a data protection section in the API spec, not sure if that covers that. Also from the sounds of it, it looks like the the platform key would be different for each server.</div><div><br></div><div>Overall SEV looks great IMO.</div><div><br></div><div>Cheers,</div><div>Ricardo</div><div><br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div lang="EN-US" link="blue" vlink="purple"><div class="m_4066686932561311945WordSection1"><div style="border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in 4.0pt"><div><div><div><div><p class="MsoNormal"><u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">Sincerely,<u></u><u></u></p>
<p class="MsoNormal">Jesse<u></u><u></u></p>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</blockquote></div><br></div></div>