On Thu, Sep 15, 2016 at 01:05:12AM +0300, Michael S. Tsirkin wrote:
[...]
> > > Attestation seems mostly unrelated. The whitepaper says
> > > With this attestation, a guest owner can ensure that the hypervisor did
> > > not interfere with the initialization of SEV before transmitting
> > > co
On Wed, Sep 14, 2016 at 02:35:41PM -0300, Eduardo Habkost wrote:
> On Wed, Sep 14, 2016 at 06:46:20PM +0300, Michael S. Tsirkin wrote:
> > On Wed, Sep 14, 2016 at 04:06:33PM +0100, Daniel P. Berrange wrote:
> > > On Wed, Sep 14, 2016 at 05:48:17PM +0300, Michael S. Tsirkin wrote:
> > > > On Wed, Se
On Wed, Sep 14, 2016 at 10:44:58PM +0200, Paolo Bonzini wrote:
>
>
> On 14/09/2016 22:36, Michael S. Tsirkin wrote:
> > Specifically with debug, if you have debug then clearly you
> > can dump guest memory. This is what this feature is about.
> > If we want a hypervisor that can not dump guest me
On 09/14/2016 03:44 PM, Paolo Bonzini wrote:
On 14/09/2016 22:36, Michael S. Tsirkin wrote:
Specifically with debug, if you have debug then clearly you
can dump guest memory. This is what this feature is about.
If we want a hypervisor that can not dump guest memory, let's
add a flag like tha
On 14/09/2016 22:36, Michael S. Tsirkin wrote:
> Specifically with debug, if you have debug then clearly you
> can dump guest memory. This is what this feature is about.
> If we want a hypervisor that can not dump guest memory, let's
> add a flag like that. Does everyone have to disable debugging
On Wed, Sep 14, 2016 at 09:58:25PM +0200, Paolo Bonzini wrote:
>
>
> On 14/09/2016 21:24, Michael S. Tsirkin wrote:
> > Well limited protection is of a limited use :) Seriously, the point of
> > mitigation should be blocking classes of vulenrabilities not making
> > things more complex.
>
> No,
On 14/09/2016 21:24, Michael S. Tsirkin wrote:
> Well limited protection is of a limited use :) Seriously, the point of
> mitigation should be blocking classes of vulenrabilities not making
> things more complex.
No, not at all. The point of _mitigation_ is to _mitigate_ the danger
from classes
On Wed, Sep 14, 2016 at 08:45:25PM +0200, Paolo Bonzini wrote:
>
>
> On 14/09/2016 20:15, Michael S. Tsirkin wrote:
> > On Wed, Sep 14, 2016 at 06:53:22PM +0200, Paolo Bonzini wrote:
> >>
> >>
> >> On 14/09/2016 17:02, Michael S. Tsirkin wrote:
> >>> If you believe there are attackers that have a
On 14/09/2016 20:15, Michael S. Tsirkin wrote:
> On Wed, Sep 14, 2016 at 06:53:22PM +0200, Paolo Bonzini wrote:
>>
>>
>> On 14/09/2016 17:02, Michael S. Tsirkin wrote:
>>> If you believe there are attackers that have access to the
>>> monitor and nothing else, then a feature to disable debugging
On Wed, Sep 14, 2016 at 06:53:22PM +0200, Paolo Bonzini wrote:
>
>
> On 14/09/2016 17:02, Michael S. Tsirkin wrote:
> > If you believe there are attackers that have access to the
> > monitor and nothing else, then a feature to disable debugging
> > is a generally useful one. But once we merge sev
On Wed, Sep 14, 2016 at 06:46:20PM +0300, Michael S. Tsirkin wrote:
> On Wed, Sep 14, 2016 at 04:06:33PM +0100, Daniel P. Berrange wrote:
> > On Wed, Sep 14, 2016 at 05:48:17PM +0300, Michael S. Tsirkin wrote:
> > > On Wed, Sep 14, 2016 at 03:15:07PM +0100, Daniel P. Berrange wrote:
> > > > On Wed,
On 14/09/2016 17:02, Michael S. Tsirkin wrote:
> If you believe there are attackers that have access to the
> monitor and nothing else, then a feature to disable debugging
> is a generally useful one. But once we merge sev patchset then of course
> sev people disappear and it will be up to others
On Wed, Sep 14, 2016 at 04:06:33PM +0100, Daniel P. Berrange wrote:
> On Wed, Sep 14, 2016 at 05:48:17PM +0300, Michael S. Tsirkin wrote:
> > On Wed, Sep 14, 2016 at 03:15:07PM +0100, Daniel P. Berrange wrote:
> > > On Wed, Sep 14, 2016 at 04:50:51PM +0300, Michael S. Tsirkin wrote:
> > > > On Wed,
On Wed, Sep 14, 2016 at 11:08:45AM -0300, Eduardo Habkost wrote:
> On Wed, Sep 14, 2016 at 04:50:51PM +0300, Michael S. Tsirkin wrote:
> > On Wed, Sep 14, 2016 at 02:37:49PM +0100, Daniel P. Berrange wrote:
> > > On Wed, Sep 14, 2016 at 04:32:44PM +0300, Michael S. Tsirkin wrote:
> > > > On Wed, Se
On Wed, Sep 14, 2016 at 05:48:17PM +0300, Michael S. Tsirkin wrote:
> On Wed, Sep 14, 2016 at 03:15:07PM +0100, Daniel P. Berrange wrote:
> > On Wed, Sep 14, 2016 at 04:50:51PM +0300, Michael S. Tsirkin wrote:
> > > On Wed, Sep 14, 2016 at 02:37:49PM +0100, Daniel P. Berrange wrote:
> > > > On Wed,
On Wed, Sep 14, 2016 at 04:19:38PM +0200, Paolo Bonzini wrote:
>
>
> On 14/09/2016 15:48, Michael S. Tsirkin wrote:
> >> One of the bit in policy field is "debugging", if this bit is set then
> >> hypervisor can use SEV commands to decrypt a guest memory
> >
> > That is my point. Arbitrary code
On Wed, Sep 14, 2016 at 03:15:07PM +0100, Daniel P. Berrange wrote:
> On Wed, Sep 14, 2016 at 04:50:51PM +0300, Michael S. Tsirkin wrote:
> > On Wed, Sep 14, 2016 at 02:37:49PM +0100, Daniel P. Berrange wrote:
> > > On Wed, Sep 14, 2016 at 04:32:44PM +0300, Michael S. Tsirkin wrote:
> > > > On Wed,
On Wed, Sep 14, 2016 at 04:14:04PM +0200, Paolo Bonzini wrote:
>
>
> On 14/09/2016 16:08, Eduardo Habkost wrote:
> >> > If attacker can trigger things, IOW execute code in hypervisor,
> >> > then encrypting memory is not useful anyway.
> > I believe the whole point of SEV attestation and key mana
On 14/09/2016 15:48, Michael S. Tsirkin wrote:
>> One of the bit in policy field is "debugging", if this bit is set then
>> hypervisor can use SEV commands to decrypt a guest memory
>
> That is my point. Arbitrary code execution in hypervisor means game over
> anyway, at least with the hardware
On 14/09/2016 16:08, Eduardo Habkost wrote:
>> > If attacker can trigger things, IOW execute code in hypervisor,
>> > then encrypting memory is not useful anyway.
> I believe the whole point of SEV attestation and key management
> is to make "if attacker can executed code in hypervisor,
> encrypt
On Wed, Sep 14, 2016 at 04:50:51PM +0300, Michael S. Tsirkin wrote:
> On Wed, Sep 14, 2016 at 02:37:49PM +0100, Daniel P. Berrange wrote:
> > On Wed, Sep 14, 2016 at 04:32:44PM +0300, Michael S. Tsirkin wrote:
> > > On Wed, Sep 14, 2016 at 02:23:14PM +0100, Daniel P. Berrange wrote:
> > > > On Wed,
On Wed, Sep 14, 2016 at 04:50:51PM +0300, Michael S. Tsirkin wrote:
> On Wed, Sep 14, 2016 at 02:37:49PM +0100, Daniel P. Berrange wrote:
> > On Wed, Sep 14, 2016 at 04:32:44PM +0300, Michael S. Tsirkin wrote:
> > > On Wed, Sep 14, 2016 at 02:23:14PM +0100, Daniel P. Berrange wrote:
> > > > On Wed,
On Wed, Sep 14, 2016 at 02:37:49PM +0100, Daniel P. Berrange wrote:
> On Wed, Sep 14, 2016 at 04:32:44PM +0300, Michael S. Tsirkin wrote:
> > On Wed, Sep 14, 2016 at 02:23:14PM +0100, Daniel P. Berrange wrote:
> > > On Wed, Sep 14, 2016 at 03:07:58PM +0200, Paolo Bonzini wrote:
> > > >
> > > >
>
On Wed, Sep 14, 2016 at 08:36:50AM -0500, Brijesh Singh wrote:
> On 09/13/2016 09:28 PM, Michael S. Tsirkin wrote:
> > On Tue, Sep 13, 2016 at 10:48:27AM -0400, Brijesh Singh wrote:
> > > The SEV DEBUG_DECRYPT command is used for decrypting a guest memory
> > > for the debugging purposes. Note that
On 09/13/2016 09:28 PM, Michael S. Tsirkin wrote:
On Tue, Sep 13, 2016 at 10:48:27AM -0400, Brijesh Singh wrote:
The SEV DEBUG_DECRYPT command is used for decrypting a guest memory
for the debugging purposes. Note that debugging is permitting only
when guest policy allows it.
When wouldn't you
On Wed, Sep 14, 2016 at 04:32:44PM +0300, Michael S. Tsirkin wrote:
> On Wed, Sep 14, 2016 at 02:23:14PM +0100, Daniel P. Berrange wrote:
> > On Wed, Sep 14, 2016 at 03:07:58PM +0200, Paolo Bonzini wrote:
> > >
> > >
> > > On 14/09/2016 15:05, Michael S. Tsirkin wrote:
> > > > I assumed that with
On Wed, Sep 14, 2016 at 02:23:14PM +0100, Daniel P. Berrange wrote:
> On Wed, Sep 14, 2016 at 03:07:58PM +0200, Paolo Bonzini wrote:
> >
> >
> > On 14/09/2016 15:05, Michael S. Tsirkin wrote:
> > > I assumed that with debug on, memory is still encrypted but the
> > > hypervisor can break encrypti
On Wed, Sep 14, 2016 at 03:07:58PM +0200, Paolo Bonzini wrote:
>
>
> On 14/09/2016 15:05, Michael S. Tsirkin wrote:
> > I assumed that with debug on, memory is still encrypted but the
> > hypervisor can break encryption, and as the cover letter states, the
> > hypervisor is assumed benign. If tru
On Wed, Sep 14, 2016 at 10:57:34AM +0200, Paolo Bonzini wrote:
>
>
> On 14/09/2016 04:28, Michael S. Tsirkin wrote:
> > On Tue, Sep 13, 2016 at 10:48:27AM -0400, Brijesh Singh wrote:
> >> The SEV DEBUG_DECRYPT command is used for decrypting a guest memory
> >> for the debugging purposes. Note tha
On 14/09/2016 15:05, Michael S. Tsirkin wrote:
> I assumed that with debug on, memory is still encrypted but the
> hypervisor can break encryption, and as the cover letter states, the
> hypervisor is assumed benign. If true I don't see a need to
> give users more rope.
The hypervisor is assumed
On 14/09/2016 04:28, Michael S. Tsirkin wrote:
> On Tue, Sep 13, 2016 at 10:48:27AM -0400, Brijesh Singh wrote:
>> The SEV DEBUG_DECRYPT command is used for decrypting a guest memory
>> for the debugging purposes. Note that debugging is permitting only
>> when guest policy allows it.
>
> When wo
On Tue, Sep 13, 2016 at 10:48:27AM -0400, Brijesh Singh wrote:
> The SEV DEBUG_DECRYPT command is used for decrypting a guest memory
> for the debugging purposes. Note that debugging is permitting only
> when guest policy allows it.
When wouldn't you want to allow it?
I don't see value in a "break
The SEV DEBUG_DECRYPT command is used for decrypting a guest memory
for the debugging purposes. Note that debugging is permitting only
when guest policy allows it.
For more information see [1], section 7.1
[1] http://support.amd.com/TechDocs/55766_SEV-KM%20API_Spec.pdf
The following KVM RFC patc
33 matches
Mail list logo
