On 10/18/17 8:35 PM, Michael S. Tsirkin wrote:
On Wed, Oct 18, 2017 at 08:18:48PM +0100, Dr. David Alan Gilbert wrote:
* Michael S. Tsirkin (m...@redhat.com) wrote:
On Fri, Sep 08, 2017 at 10:48:10AM -0500, Brijesh Singh wrote:
> 11. GO verifies the measurement and if measurement matches
On Wed, Oct 18, 2017 at 08:18:48PM +0100, Dr. David Alan Gilbert wrote:
> * Michael S. Tsirkin (m...@redhat.com) wrote:
> > On Fri, Sep 08, 2017 at 10:48:10AM -0500, Brijesh Singh wrote:
> > > > > > 11. GO verifies the measurement and if measurement matches
> > > > > then it may
> > > > >
* Michael S. Tsirkin (m...@redhat.com) wrote:
> On Fri, Sep 08, 2017 at 10:48:10AM -0500, Brijesh Singh wrote:
> > > > > 11. GO verifies the measurement and if measurement matches then
> > > > it may
> > > > > give a secret blob -- which must be injected into the guest
> > > > before
>
On Fri, Sep 08, 2017 at 10:48:10AM -0500, Brijesh Singh wrote:
> > > > 11. GO verifies the measurement and if measurement matches then it
> > > may
> > > > give a secret blob -- which must be injected into the guest before
> > > > libvirt starts the VM. If verification failed, GO
Hi Laszlo,
On 10/01/2017 04:56 AM, Laszlo Ersek wrote:
On 10/01/17 11:17, Laszlo Ersek wrote:
(3) Implement SEV encryption for pflash. A pflash chip can be in one of
two modes: (a) it reads and executes as ROM, or (b) it behaves like a
programmable (r/w) device with MMIO registers. Switching
On Sat, Sep 30, 2017 at 12:16:55AM +0300, Michael S. Tsirkin wrote:
> On Fri, Sep 29, 2017 at 02:48:45PM -0500, Richard Relph wrote:
> > On 9/29/17 2:34 PM, Michael S. Tsirkin wrote:
> > > On Wed, Sep 27, 2017 at 02:06:10PM -0500, Richard Relph wrote:
> > > > Whether the "BIOS" is a "static shim" a
On Fri, Sep 29, 2017 at 02:48:45PM -0500, Richard Relph wrote:
> On 9/29/17 2:34 PM, Michael S. Tsirkin wrote:
> > On Wed, Sep 27, 2017 at 02:06:10PM -0500, Richard Relph wrote:
> > > Whether the "BIOS" is a "static shim" as Michael suggests, or a full BIOS,
> > > or even a BIOS+kernel+initrd is re
On 10/01/17 11:17, Laszlo Ersek wrote:
> (3) Implement SEV encryption for pflash. A pflash chip can be in one of
> two modes: (a) it reads and executes as ROM, or (b) it behaves like a
> programmable (r/w) device with MMIO registers. Switching between both
> modes is explicit (see
> "OvmfPkg/QemuF
On 10/01/17 02:09, Brijesh Singh wrote:
>
>
> On 9/29/17 4:58 PM, Laszlo Ersek wrote:
> ...
>> The expansion ROMs (containing UEFI drivers) of emulated PCI devices,
>> and the same of assigned physical PCI devices, constitute another
>> channel through which code enters the guest from the outside
On Fri, Sep 29, 2017 at 03:07:40PM -0500, Richard Relph wrote:
> Depending on your level of paranoia,
> that may require advance notice of BIOS changes, or even allowing the GO to
> provide the BIOS themselves, written to a spec supported by the CP's HV,
> and/or based on BIOS code provided by the
On Fri, Sep 29, 2017 at 03:07:40PM -0500, Richard Relph wrote:
> It's a business decision and I think SEV can support both.
I think what has been missed in the noise is the fact that
with VM launch, key distribution is a huge problem.
With the shim the key distribution problem can go completely a
On 9/29/17 4:58 PM, Laszlo Ersek wrote:
...
> The expansion ROMs (containing UEFI drivers) of emulated PCI devices,
> and the same of assigned physical PCI devices, constitute another
> channel through which code enters the guest from the outside (i.e., from
> the Cloud Provider). The ROM BARs fr
On 09/29/17 23:16, Michael S. Tsirkin wrote:
> On Fri, Sep 29, 2017 at 02:48:45PM -0500, Richard Relph wrote:
>> On 9/29/17 2:34 PM, Michael S. Tsirkin wrote:
>>> On Wed, Sep 27, 2017 at 02:06:10PM -0500, Richard Relph wrote:
Whether the "BIOS" is a "static shim" as Michael suggests, or a full
Side topic; sorry if it has been mentioned elsewhere:
On 09/27/17 21:06, Richard Relph wrote:
> Whether the "BIOS" is a "static shim" as Michael suggests, or a full
> BIOS, or even a BIOS+kernel+initrd is really not too significant. What
> is significant is that the GO has a basis for trusting al
On Fri, Sep 29, 2017 at 02:48:45PM -0500, Richard Relph wrote:
> On 9/29/17 2:34 PM, Michael S. Tsirkin wrote:
> > On Wed, Sep 27, 2017 at 02:06:10PM -0500, Richard Relph wrote:
> > > Whether the "BIOS" is a "static shim" as Michael suggests, or a full BIOS,
> > > or even a BIOS+kernel+initrd is re
On Fri, Sep 29, 2017 at 03:07:40PM -0500, Richard Relph wrote:
> On 9/29/17 2:48 PM, Richard Relph wrote:
> > On 9/29/17 2:34 PM, Michael S. Tsirkin wrote:
> > > On Wed, Sep 27, 2017 at 02:06:10PM -0500, Richard Relph wrote:
> > > > Whether the "BIOS" is a "static shim" as Michael suggests, or a
>
On 9/29/17 2:34 PM, Michael S. Tsirkin wrote:
On Wed, Sep 27, 2017 at 02:06:10PM -0500, Richard Relph wrote:
Whether the "BIOS" is a "static shim" as Michael suggests, or a full BIOS,
or even a BIOS+kernel+initrd is really not too significant. What is
significant is that the GO has a basis for t
On 9/29/17 2:48 PM, Richard Relph wrote:
On 9/29/17 2:34 PM, Michael S. Tsirkin wrote:
On Wed, Sep 27, 2017 at 02:06:10PM -0500, Richard Relph wrote:
Whether the "BIOS" is a "static shim" as Michael suggests, or a full
BIOS,
or even a BIOS+kernel+initrd is really not too significant. What is
s
On Wed, Sep 27, 2017 at 02:06:10PM -0500, Richard Relph wrote:
> Whether the "BIOS" is a "static shim" as Michael suggests, or a full BIOS,
> or even a BIOS+kernel+initrd is really not too significant. What is
> significant is that the GO has a basis for trusting all code that is
> imported in to t
Forgive the top post... some of the conversation has been trimmed, but I
need to go back to first principles of SEV in order to make sure we all
have a clear understanding of what the goal is.
The goal - for BOTH guest owner and cloud provider - is to get to a VM
where ONLY the guest owner (GO
On Wed, Sep 27, 2017 at 08:39:24AM -0500, Brijesh Singh wrote:
> Hi Michael,
>
>
> On 09/26/2017 09:36 AM, Michael S. Tsirkin wrote:
>
> ...
>
> > > 8. libvirt launches the guest with "-S"
> > > 9. While creating the SEV guest qemu does the following
> > > i) create encryption context using G
Hi Michael,
On 09/26/2017 09:36 AM, Michael S. Tsirkin wrote:
...
8. libvirt launches the guest with "-S"
9. While creating the SEV guest qemu does the following
i) create encryption context using GO's DH, session-info and guest policy
(LAUNCH_START)
ii) encrypts the guest bios (LAUN
* Michael S. Tsirkin (m...@redhat.com) wrote:
> On Fri, Sep 08, 2017 at 06:57:30AM -0500, Brijesh Singh wrote:
> > Hi All,
>
> Sorry if below comment doesn't make sense, I might be misunderstanding
> something basic about SEV. Also sorry about the delay, I've been on
> vacation.
>
>
> > (sorry f
On Fri, Sep 08, 2017 at 06:57:30AM -0500, Brijesh Singh wrote:
> Hi All,
Sorry if below comment doesn't make sense, I might be misunderstanding
something basic about SEV. Also sorry about the delay, I've been on
vacation.
> (sorry for the long message)
>
> CPUs from AMD EPYC family supports Sec
On Mon, Sep 18, 2017 at 07:41:09AM -0500, Richard Relph wrote:
>
>
> On 9/18/17 4:47 AM, Daniel P. Berrange wrote:
> > On Mon, Sep 18, 2017 at 11:43:57AM +0200, Erik Skultety wrote:
> > > [...]
> > >
> > > > > > c) what existing communicate interface can be used between
> > > > > libvirt and
On 9/18/17 4:47 AM, Daniel P. Berrange wrote:
On Mon, Sep 18, 2017 at 11:43:57AM +0200, Erik Skultety wrote:
[...]
> c) what existing communicate interface can be used between libvirt and
qemu
> to get the measurement ? can we add a new qemu monitor command
> 'get_sev_measure
On Mon, Sep 18, 2017 at 11:43:57AM +0200, Erik Skultety wrote:
> [...]
>
> > >
> > > > c) what existing communicate interface can be used between libvirt
> > > and qemu
> > > > to get the measurement ? can we add a new qemu monitor command
> > > > 'get_sev_measurement' to get the meas
[...]
> >
> > > c) what existing communicate interface can be used between libvirt
> > and qemu
> > > to get the measurement ? can we add a new qemu monitor command
> > > 'get_sev_measurement' to get the measurement ? (step 10)
> >
> > Yes, QMP commands seeem most likely.
> >
> >
On 09/08/2017 10:51 AM, Daniel P. Berrange wrote:
On Fri, Sep 08, 2017 at 10:48:10AM -0500, Brijesh Singh wrote:
So I could see a flow like the following:
The flow looks good
1. mgmt tool calls virConnectGetCapabilities. This returns an XML
document that includes the followi
On 09/08/17 17:51, Daniel P. Berrange wrote:
> On Fri, Sep 08, 2017 at 10:48:10AM -0500, Brijesh Singh wrote:
>> I am looking at [1] to get the feel for how do we model it in the XML.
>> As you can see I am using ad-hoc to create the sev-guest
>> object. Currently, sev-guest object accepts the fo
Hi Daniel,
On 09/08/2017 09:52 AM, Daniel P. Berrange wrote:
On Fri, Sep 08, 2017 at 01:45:06PM +, Relph, Richard wrote:
A few answers in line…
On 9/8/17, 8:16 AM, "Daniel P. Berrange" wrote:
On Fri, Sep 08, 2017 at 06:57:30AM -0500, Brijesh Singh wrote:
> Hi All,
>
On Fri, Sep 08, 2017 at 10:48:10AM -0500, Brijesh Singh wrote:
> > So I could see a flow like the following:
>
>
> The flow looks good
>
> >
> >
> >1. mgmt tool calls virConnectGetCapabilities. This returns an XML
> > document that includes the following
> >
> >
> >
On Fri, Sep 08, 2017 at 01:45:06PM +, Relph, Richard wrote:
> A few answers in line…
>
> On 9/8/17, 8:16 AM, "Daniel P. Berrange" wrote:
>
> On Fri, Sep 08, 2017 at 06:57:30AM -0500, Brijesh Singh wrote:
> > Hi All,
> >
> > (sorry for the long message)
> >
> > CPUs
A few answers in line…
On 9/8/17, 8:16 AM, "Daniel P. Berrange" wrote:
On Fri, Sep 08, 2017 at 06:57:30AM -0500, Brijesh Singh wrote:
> Hi All,
>
> (sorry for the long message)
>
> CPUs from AMD EPYC family supports Secure Encrypted Virtualization (SEV)
> feature -
On Fri, Sep 08, 2017 at 06:57:30AM -0500, Brijesh Singh wrote:
> Hi All,
>
> (sorry for the long message)
>
> CPUs from AMD EPYC family supports Secure Encrypted Virtualization (SEV)
> feature - the feature allows running encrypted VMs. To enable the feature,
> I have been submitting patches to L
35 matches
Mail list logo
