Re: [RFC v2 00/18] Refactor configuration of guest memory protection

2020-06-09 Thread David Gibson
On Tue, Jun 09, 2020 at 12:11:05PM +0200, Halil Pasic wrote: > On Sat, 6 Jun 2020 18:44:09 +1000 > David Gibson wrote: > > > On Fri, Jun 05, 2020 at 12:55:05PM +0200, Cornelia Huck wrote: > > > On Thu, 21 May 2020 13:42:46 +1000 > > > David Gibson wrote: > > > > > > > A number of hardware

Re: [RFC v2 00/18] Refactor configuration of guest memory protection

2020-06-09 Thread Halil Pasic
On Sat, 6 Jun 2020 18:44:09 +1000 David Gibson wrote: > On Fri, Jun 05, 2020 at 12:55:05PM +0200, Cornelia Huck wrote: > > On Thu, 21 May 2020 13:42:46 +1000 > > David Gibson wrote: > > > > > A number of hardware platforms are implementing mechanisms whereby the > > > hypervisor does not have

Re: [RFC v2 00/18] Refactor configuration of guest memory protection

2020-06-08 Thread Thiago Jung Bauermann
David Gibson writes: > On Fri, Jun 05, 2020 at 05:01:07PM -0300, Thiago Jung Bauermann wrote: >> >> Paolo Bonzini writes: >> >> > On 05/06/20 01:30, Thiago Jung Bauermann wrote: >> >> Paolo Bonzini writes: >> >>> On 04/06/20 23:54, Thiago Jung Bauermann wrote: >> QEMU could always

Re: [RFC v2 00/18] Refactor configuration of guest memory protection

2020-06-06 Thread David Gibson
On Fri, Jun 05, 2020 at 12:55:05PM +0200, Cornelia Huck wrote: > On Thu, 21 May 2020 13:42:46 +1000 > David Gibson wrote: > > > A number of hardware platforms are implementing mechanisms whereby the > > hypervisor does not have unfettered access to guest memory, in order > > to mitigate the

Re: [RFC v2 00/18] Refactor configuration of guest memory protection

2020-06-06 Thread David Gibson
On Thu, Jun 04, 2020 at 11:08:21AM +0200, Greg Kurz wrote: > On Thu, 4 Jun 2020 16:44:14 +1000 > David Gibson wrote: > > > On Thu, Jun 04, 2020 at 01:39:22AM -0300, Thiago Jung Bauermann wrote: > > > > > > Hello David, > > > > > > David Gibson writes: > > > > > > > A number of hardware

Re: [RFC v2 00/18] Refactor configuration of guest memory protection

2020-06-06 Thread David Gibson
On Fri, Jun 05, 2020 at 05:01:07PM -0300, Thiago Jung Bauermann wrote: > > Paolo Bonzini writes: > > > On 05/06/20 01:30, Thiago Jung Bauermann wrote: > >> Paolo Bonzini writes: > >>> On 04/06/20 23:54, Thiago Jung Bauermann wrote: > QEMU could always create a PEF object, and if the

Re: [RFC v2 00/18] Refactor configuration of guest memory protection

2020-06-05 Thread Thiago Jung Bauermann
Paolo Bonzini writes: > On 05/06/20 01:30, Thiago Jung Bauermann wrote: >> Paolo Bonzini writes: >>> On 04/06/20 23:54, Thiago Jung Bauermann wrote: QEMU could always create a PEF object, and if the command line defines one, it will correspond to it. And if the command line doesn't

Re: [RFC v2 00/18] Refactor configuration of guest memory protection

2020-06-05 Thread Cornelia Huck
On Thu, 21 May 2020 13:42:46 +1000 David Gibson wrote: > A number of hardware platforms are implementing mechanisms whereby the > hypervisor does not have unfettered access to guest memory, in order > to mitigate the security impact of a compromised hypervisor. > > AMD's SEV implements this

Re: [RFC v2 00/18] Refactor configuration of guest memory protection

2020-06-04 Thread Paolo Bonzini
On 05/06/20 01:30, Thiago Jung Bauermann wrote: > Paolo Bonzini writes: >> On 04/06/20 23:54, Thiago Jung Bauermann wrote: >>> QEMU could always create a PEF object, and if the command line defines >>> one, it will correspond to it. And if the command line doesn't define one, >>> then it would

Re: [RFC v2 00/18] Refactor configuration of guest memory protection

2020-06-04 Thread Thiago Jung Bauermann
Paolo Bonzini writes: > On 04/06/20 23:54, Thiago Jung Bauermann wrote: >> QEMU could always create a PEF object, and if the command line defines >> one, it will correspond to it. And if the command line doesn't define one, >> then it would also work because the PEF object is already there. >

Re: [RFC v2 00/18] Refactor configuration of guest memory protection

2020-06-04 Thread Paolo Bonzini
On 04/06/20 23:54, Thiago Jung Bauermann wrote: > QEMU could always create a PEF object, and if the command line defines > one, it will correspond to it. And if the command line doesn't define one, > then it would also work because the PEF object is already there. How would you start a

Re: [RFC v2 00/18] Refactor configuration of guest memory protection

2020-06-04 Thread Thiago Jung Bauermann
David Gibson writes: > On Thu, Jun 04, 2020 at 01:39:22AM -0300, Thiago Jung Bauermann wrote: >> >> Hello David, >> >> David Gibson writes: >> >> > A number of hardware platforms are implementing mechanisms whereby the >> > hypervisor does not have unfettered access to guest memory, in

Re: [RFC v2 00/18] Refactor configuration of guest memory protection

2020-06-04 Thread Sean Christopherson
On Thu, Jun 04, 2020 at 01:11:29PM +1000, David Gibson wrote: > On Mon, Jun 01, 2020 at 10:16:18AM +0100, Dr. David Alan Gilbert wrote: > > * Sean Christopherson (sean.j.christopher...@intel.com) wrote: > > > On Thu, May 21, 2020 at 01:42:46PM +1000, David Gibson wrote: > > > > Note: I'm using the

Re: [RFC v2 00/18] Refactor configuration of guest memory protection

2020-06-04 Thread Greg Kurz
On Thu, 4 Jun 2020 16:44:14 +1000 David Gibson wrote: > On Thu, Jun 04, 2020 at 01:39:22AM -0300, Thiago Jung Bauermann wrote: > > > > Hello David, > > > > David Gibson writes: > > > > > A number of hardware platforms are implementing mechanisms whereby the > > > hypervisor does not have

Re: [RFC v2 00/18] Refactor configuration of guest memory protection

2020-06-04 Thread Thiago Jung Bauermann
Hello David, David Gibson writes: > A number of hardware platforms are implementing mechanisms whereby the > hypervisor does not have unfettered access to guest memory, in order > to mitigate the security impact of a compromised hypervisor. > > AMD's SEV implements this with in-cpu memory

Re: [RFC v2 00/18] Refactor configuration of guest memory protection

2020-06-04 Thread David Gibson
On Thu, Jun 04, 2020 at 01:39:22AM -0300, Thiago Jung Bauermann wrote: > > Hello David, > > David Gibson writes: > > > A number of hardware platforms are implementing mechanisms whereby the > > hypervisor does not have unfettered access to guest memory, in order > > to mitigate the security

Re: [RFC v2 00/18] Refactor configuration of guest memory protection

2020-06-04 Thread David Gibson
On Thu, Jun 04, 2020 at 01:39:22AM -0300, Thiago Jung Bauermann wrote: > > Hello David, > > David Gibson writes: > > > A number of hardware platforms are implementing mechanisms whereby the > > hypervisor does not have unfettered access to guest memory, in order > > to mitigate the security

Re: [RFC v2 00/18] Refactor configuration of guest memory protection

2020-06-04 Thread David Gibson
On Mon, Jun 01, 2020 at 10:16:18AM +0100, Dr. David Alan Gilbert wrote: > * Sean Christopherson (sean.j.christopher...@intel.com) wrote: > > On Thu, May 21, 2020 at 01:42:46PM +1000, David Gibson wrote: > > > A number of hardware platforms are implementing mechanisms whereby the > > > hypervisor

Re: [RFC v2 00/18] Refactor configuration of guest memory protection

2020-06-04 Thread David Gibson
On Fri, May 29, 2020 at 03:19:26PM -0700, Sean Christopherson wrote: > On Thu, May 21, 2020 at 01:42:46PM +1000, David Gibson wrote: > > A number of hardware platforms are implementing mechanisms whereby the > > hypervisor does not have unfettered access to guest memory, in order > > to mitigate

Re: [RFC v2 00/18] Refactor configuration of guest memory protection

2020-06-01 Thread Dr. David Alan Gilbert
* Sean Christopherson (sean.j.christopher...@intel.com) wrote: > On Thu, May 21, 2020 at 01:42:46PM +1000, David Gibson wrote: > > A number of hardware platforms are implementing mechanisms whereby the > > hypervisor does not have unfettered access to guest memory, in order > > to mitigate the

Re: [RFC v2 00/18] Refactor configuration of guest memory protection

2020-05-29 Thread Sean Christopherson
On Thu, May 21, 2020 at 01:42:46PM +1000, David Gibson wrote: > A number of hardware platforms are implementing mechanisms whereby the > hypervisor does not have unfettered access to guest memory, in order > to mitigate the security impact of a compromised hypervisor. > > AMD's SEV implements

[RFC v2 00/18] Refactor configuration of guest memory protection

2020-05-20 Thread David Gibson
A number of hardware platforms are implementing mechanisms whereby the hypervisor does not have unfettered access to guest memory, in order to mitigate the security impact of a compromised hypervisor. AMD's SEV implements this with in-cpu memory encryption, and Intel has its own memory encryption