Re: [RFC 00/16] KVM protected memory extension

2020-06-04 Thread Nakajima, Jun
> > On Jun 4, 2020, at 2:03 PM, Jim Mattson wrote: > > On Thu, Jun 4, 2020 at 12:09 PM Nakajima, Jun wrote: > >> We (Intel virtualization team) are also working on a similar thing, >> prototyping to meet such requirements, i..e "some level of confidentiality >> to guests”. Linux/KVM is the

Re: [RFC 00/16] KVM protected memory extension

2020-06-04 Thread Jim Mattson
On Thu, Jun 4, 2020 at 12:09 PM Nakajima, Jun wrote: > We (Intel virtualization team) are also working on a similar thing, > prototyping to meet such requirements, i..e "some level of confidentiality to > guests”. Linux/KVM is the host, and the Kirill’s patches are helpful when > removing the

Re: [RFC 00/16] KVM protected memory extension

2020-06-04 Thread Nakajima, Jun
> > On Jun 4, 2020, at 9:35 AM, Will Deacon wrote: > > Hi Sean, > > On Thu, Jun 04, 2020 at 08:48:35AM -0700, Sean Christopherson wrote: >> On Thu, Jun 04, 2020 at 04:15:23PM +0100, Marc Zyngier wrote: >>> On Fri, 22 May 2020 15:51:58 +0300 >>> "Kirill A. Shutemov" wrote: >>> ==

Re: [RFC 00/16] KVM protected memory extension

2020-06-04 Thread Will Deacon
Hi Sean, On Thu, Jun 04, 2020 at 08:48:35AM -0700, Sean Christopherson wrote: > On Thu, Jun 04, 2020 at 04:15:23PM +0100, Marc Zyngier wrote: > > On Fri, 22 May 2020 15:51:58 +0300 > > "Kirill A. Shutemov" wrote: > > > > > == Background / Problem == > > > > > > There are a number of hardware

Re: [RFC 00/16] KVM protected memory extension

2020-06-04 Thread Marc Zyngier
Hi Sean, On 2020-06-04 16:48, Sean Christopherson wrote: +Jun On Thu, Jun 04, 2020 at 04:15:23PM +0100, Marc Zyngier wrote: Hi Kirill, Thanks for this. On Fri, 22 May 2020 15:51:58 +0300 "Kirill A. Shutemov" wrote: > == Background / Problem == > > There are a number of hardware features

Re: [RFC 00/16] KVM protected memory extension

2020-06-04 Thread Sean Christopherson
+Jun On Thu, Jun 04, 2020 at 04:15:23PM +0100, Marc Zyngier wrote: > Hi Kirill, > > Thanks for this. > > On Fri, 22 May 2020 15:51:58 +0300 > "Kirill A. Shutemov" wrote: > > > == Background / Problem == > > > > There are a number of hardware features (MKTME, SEV) which protect guest > >

Re: [RFC 00/16] KVM protected memory extension

2020-06-04 Thread Marc Zyngier
Hi Kirill, Thanks for this. On Fri, 22 May 2020 15:51:58 +0300 "Kirill A. Shutemov" wrote: > == Background / Problem == > > There are a number of hardware features (MKTME, SEV) which protect guest > memory from some unauthorized host access. The patchset proposes a purely > software feature

Re: [RFC 00/16] KVM protected memory extension

2020-05-27 Thread Mike Rapoport
On Wed, May 27, 2020 at 08:45:33AM -0700, Dave Hansen wrote: > On 5/26/20 4:38 AM, Mike Rapoport wrote: > > On Tue, May 26, 2020 at 01:16:14PM +0300, Liran Alon wrote: > >> On 26/05/2020 9:17, Mike Rapoport wrote: > >>> On Mon, May 25, 2020 at 04:47:18PM +0300, Liran Alon wrote: > On

Re: [RFC 00/16] KVM protected memory extension

2020-05-27 Thread Dave Hansen
On 5/26/20 4:38 AM, Mike Rapoport wrote: > On Tue, May 26, 2020 at 01:16:14PM +0300, Liran Alon wrote: >> On 26/05/2020 9:17, Mike Rapoport wrote: >>> On Mon, May 25, 2020 at 04:47:18PM +0300, Liran Alon wrote: On 22/05/2020 15:51, Kirill A. Shutemov wrote: >>> Out of curiosity, do we

Re: [RFC 00/16] KVM protected memory extension

2020-05-26 Thread Mike Rapoport
On Tue, May 26, 2020 at 01:16:14PM +0300, Liran Alon wrote: > > On 26/05/2020 9:17, Mike Rapoport wrote: > > On Mon, May 25, 2020 at 04:47:18PM +0300, Liran Alon wrote: > > > On 22/05/2020 15:51, Kirill A. Shutemov wrote: > > > > > Out of curiosity, do we actually have some numbers for the

Re: [RFC 00/16] KVM protected memory extension

2020-05-26 Thread Liran Alon
On 26/05/2020 9:17, Mike Rapoport wrote: On Mon, May 25, 2020 at 04:47:18PM +0300, Liran Alon wrote: On 22/05/2020 15:51, Kirill A. Shutemov wrote: Furthermore, I would like to point out that just unmapping guest data from kernel direct-map is not sufficient to prevent all guest-to-guest

Re: [RFC 00/16] KVM protected memory extension

2020-05-26 Thread Mike Rapoport
On Mon, May 25, 2020 at 04:47:18PM +0300, Liran Alon wrote: > > On 22/05/2020 15:51, Kirill A. Shutemov wrote: > > Furthermore, I would like to point out that just unmapping guest data from > kernel direct-map is not sufficient to prevent all > guest-to-guest info-leaks via a kernel memory

Re: [RFC 00/16] KVM protected memory extension

2020-05-25 Thread Liran Alon
On 25/05/2020 17:46, Kirill A. Shutemov wrote: On Mon, May 25, 2020 at 04:47:18PM +0300, Liran Alon wrote: On 22/05/2020 15:51, Kirill A. Shutemov wrote: == Background / Problem == There are a number of hardware features (MKTME, SEV) which protect guest memory from some unauthorized host

Re: [RFC 00/16] KVM protected memory extension

2020-05-25 Thread Kirill A. Shutemov
On Mon, May 25, 2020 at 04:47:18PM +0300, Liran Alon wrote: > > On 22/05/2020 15:51, Kirill A. Shutemov wrote: > > == Background / Problem == > > > > There are a number of hardware features (MKTME, SEV) which protect guest > > memory from some unauthorized host access. The patchset proposes a

Re: [RFC 00/16] KVM protected memory extension

2020-05-25 Thread Liran Alon
On 22/05/2020 15:51, Kirill A. Shutemov wrote: == Background / Problem == There are a number of hardware features (MKTME, SEV) which protect guest memory from some unauthorized host access. The patchset proposes a purely software feature that mitigates some of the same host-side read-only

Re: [RFC 00/16] KVM protected memory extension

2020-05-24 Thread Kirill A. Shutemov
On Fri, May 22, 2020 at 03:51:58PM +0300, Kirill A. Shutemov wrote: > == Background / Problem == > > There are a number of hardware features (MKTME, SEV) which protect guest > memory from some unauthorized host access. The patchset proposes a purely > software feature that mitigates some of the