On Fri, 26 Jun 2020 14:49:37 +0200
Janosch Frank wrote:
> On 6/26/20 12:58 PM, Daniel P. Berrangé wrote:
> > On Fri, Jun 26, 2020 at 11:29:03AM +0100, Dr. David Alan Gilbert wrote:
> >> * Janosch Frank (fran...@linux.ibm.com) wrote:
> >>> On 6/26/20 11:32 AM, Daniel P. Berrangé wrote:
> On
On 6/26/20 12:58 PM, Daniel P. Berrangé wrote:
> On Fri, Jun 26, 2020 at 11:29:03AM +0100, Dr. David Alan Gilbert wrote:
>> * Janosch Frank (fran...@linux.ibm.com) wrote:
>>> On 6/26/20 11:32 AM, Daniel P. Berrangé wrote:
On Fri, Jun 26, 2020 at 11:01:58AM +0200, Janosch Frank wrote:
>
On Fri, Jun 26, 2020 at 11:29:03AM +0100, Dr. David Alan Gilbert wrote:
> * Janosch Frank (fran...@linux.ibm.com) wrote:
> > On 6/26/20 11:32 AM, Daniel P. Berrangé wrote:
> > > On Fri, Jun 26, 2020 at 11:01:58AM +0200, Janosch Frank wrote:
> > >> On 6/26/20 8:53 AM, David Hildenbrand wrote:
> >
* Janosch Frank (fran...@linux.ibm.com) wrote:
> On 6/26/20 11:32 AM, Daniel P. Berrangé wrote:
> > On Fri, Jun 26, 2020 at 11:01:58AM +0200, Janosch Frank wrote:
> >> On 6/26/20 8:53 AM, David Hildenbrand wrote:
> >>> Does this have any implications when probing with the 'none' machine?
>
On 6/26/20 11:32 AM, Daniel P. Berrangé wrote:
> On Fri, Jun 26, 2020 at 11:01:58AM +0200, Janosch Frank wrote:
>> On 6/26/20 8:53 AM, David Hildenbrand wrote:
>>> Does this have any implications when probing with the 'none' machine?
>>
>> I'm not sure. In your case, I guess the cpu
On Fri, Jun 26, 2020 at 11:01:58AM +0200, Janosch Frank wrote:
> On 6/26/20 8:53 AM, David Hildenbrand wrote:
> > Does this have any implications when probing with the 'none' machine?
>
> I'm not sure. In your case, I guess the cpu bit would still show up
> as before, so it
On 6/26/20 8:53 AM, David Hildenbrand wrote:
> Does this have any implications when probing with the 'none' machine?
I'm not sure. In your case, I guess the cpu bit would still show up
as before, so it would tell you base feature availability, but not
whether you can use
Does this have any implications when probing with the 'none' machine?
>>>
>>> I'm not sure. In your case, I guess the cpu bit would still show up
>>> as before, so it would tell you base feature availability, but not
>>> whether you can use the new configuration option.
>>>
>>> Since the HTL
On Thu, Jun 25, 2020 at 09:06:05AM +0200, David Hildenbrand wrote:
> >> Still unsure how to bring this new machine property and the cpu feature
> >> together. Would be great to have the same interface everywhere, but
> >> having two distinct command line objects depend on each other sucks.
> >
>
On Thu, 25 Jun 2020 08:59:00 +0200
David Hildenbrand wrote:
> How do upper layers actually figure out if memory encryption etc is
> available? on s390x, it's simply via the expanded host CPU model.
> >>>
> >>> Haven't really tackled that yet. But one way that works for multiple
>
>> Still unsure how to bring this new machine property and the cpu feature
>> together. Would be great to have the same interface everywhere, but
>> having two distinct command line objects depend on each other sucks.
>
> Kinda, but the reality is that hardware - virtual and otherwise -
>
>
>> So it's wrapping architecture-specific data in a common
>> parameter. Hmm.
>
> Well, I don't know I'd say "wrapping". You have a common parameter
> that points to an object with a well defined interface. The available
> implementations of that object will tend to be either zero or one per
On Wed, Jun 24, 2020 at 09:06:48AM +0200, Cornelia Huck wrote:
> On Mon, 22 Jun 2020 16:27:28 +0200
> Christian Borntraeger wrote:
>
> > On 19.06.20 04:05, David Gibson wrote:
> > > A number of hardware platforms are implementing mechanisms whereby the
> > > hypervisor does not have unfettered
On Thu, Jun 25, 2020 at 03:47:23PM +1000, David Gibson wrote:
> On Wed, Jun 24, 2020 at 09:06:48AM +0200, Cornelia Huck wrote:
> > On Mon, 22 Jun 2020 16:27:28 +0200
> > Christian Borntraeger wrote:
> >
> > > On 19.06.20 04:05, David Gibson wrote:
> > > > A number of hardware platforms are
On Fri, Jun 19, 2020 at 12:04:25PM +0200, David Hildenbrand wrote:
> >> However, once we have multiple options to protect a guest (memory
> >> encryption, unmapping guest pages ,...) the name will no longer really
> >> suffice to configure QEMU, no?
> >
> > That's why it takes a parameter. It
On Mon, Jun 22, 2020 at 04:27:28PM +0200, Christian Borntraeger wrote:
> On 19.06.20 04:05, 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
On Mon, Jun 22, 2020 at 02:02:54PM +0200, Cornelia Huck wrote:
> On Fri, 19 Jun 2020 12:10:13 +0200
> David Hildenbrand wrote:
>
> > On 19.06.20 12:05, Cornelia Huck wrote:
> > > On Fri, 19 Jun 2020 11:56:49 +0200
> > > David Hildenbrand wrote:
> > >
> > > For now this series covers just
On Mon, 22 Jun 2020 16:27:28 +0200
Christian Borntraeger wrote:
> On 19.06.20 04:05, 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
On 19.06.20 04:05, 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 with in-cpu memory
On Fri, 19 Jun 2020 12:10:13 +0200
David Hildenbrand wrote:
> On 19.06.20 12:05, Cornelia Huck wrote:
> > On Fri, 19 Jun 2020 11:56:49 +0200
> > David Hildenbrand wrote:
> >
> > For now this series covers just AMD SEV and POWER PEF. I'm hoping it
> > can be extended to cover the
On 19.06.20 12:05, Cornelia Huck wrote:
> On Fri, 19 Jun 2020 11:56:49 +0200
> David Hildenbrand wrote:
>
> For now this series covers just AMD SEV and POWER PEF. I'm hoping it
> can be extended to cover the Intel and s390 mechanisms as well,
> though.
The only
On Fri, 19 Jun 2020 11:56:49 +0200
David Hildenbrand wrote:
> >>> For now this series covers just AMD SEV and POWER PEF. I'm hoping it
> >>> can be extended to cover the Intel and s390 mechanisms as well,
> >>> though.
> >>
> >> The only approach on s390x to not glue command line properties
>> However, once we have multiple options to protect a guest (memory
>> encryption, unmapping guest pages ,...) the name will no longer really
>> suffice to configure QEMU, no?
>
> That's why it takes a parameter. It points to an object which can
> itself have more properties to configure the
>> "host-trust-limitation" sounds like "I am the hypervisor, I configure
>> limited trust into myself". Also, "untrusted-host" would be a little bit
>> nicer (I think trust is a black/white thing).
>>
>> However, once we have multiple options to protect a guest (memory
>> encryption, unmapping
On Fri, Jun 19, 2020 at 10:28:22AM +0200, David Hildenbrand wrote:
> On 19.06.20 04:05, 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
On Fri, 19 Jun 2020 10:28:22 +0200
David Hildenbrand wrote:
> On 19.06.20 04:05, 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
On 19.06.20 04:05, 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 with in-cpu memory
Patchew URL:
https://patchew.org/QEMU/20200619020602.118306-1-da...@gibson.dropbear.id.au/
Hi,
This series failed the asan build test. Please find the testing commands and
their output below. If you have Docker installed, you can probably reproduce it
locally.
=== TEST SCRIPT BEGIN ===
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
29 matches
Mail list logo
