Paolo Bonzini writes:
> Il 05/03/2014 11:36, Markus Armbruster ha scritto:
>> Andreas Färber writes:
>>
>>> Am 05.03.2014 09:43, schrieb Markus Armbruster:
Kevin Wolf writes:
> 'change' is a bit trickier because it involves several low-level actions
> at once, and device_add i
Kevin Wolf writes:
> Am 05.03.2014 um 09:15 hat Markus Armbruster geschrieben:
>> Eric Blake writes:
>> > Uggh - so there's no current way to hot-plug a device in state GOTKEY
>> > short of using a two-command sequence? It would be nicer if hot-plug
>> > had a way to fail to add encrypted devic
Il 05/03/2014 11:36, Markus Armbruster ha scritto:
Andreas Färber writes:
Am 05.03.2014 09:43, schrieb Markus Armbruster:
Kevin Wolf writes:
'change' is a bit trickier because it involves several low-level actions
at once, and device_add is not one of them.
The problem is that it can run
Andreas Färber writes:
> Am 05.03.2014 09:43, schrieb Markus Armbruster:
>> Kevin Wolf writes:
>>
>>> 'change' is a bit trickier because it involves several low-level actions
>>> at once, and device_add is not one of them.
>>
>> The problem is that it can run while a device model is attached.
Am 05.03.2014 um 09:15 hat Markus Armbruster geschrieben:
> Eric Blake writes:
> > Uggh - so there's no current way to hot-plug a device in state GOTKEY
> > short of using a two-command sequence? It would be nicer if hot-plug
> > had a way to fail to add encrypted devices unless the user also pas
Paolo Bonzini writes:
> Il 05/03/2014 09:24, Markus Armbruster ha scritto:
>> Paolo Bonzini writes:
>>
>>> Il 28/02/2014 23:08, Eric Blake ha scritto:
Use the fact that we are calling the next release "2.0" to actually kill
qemu disk encryption as a horribly botched feature, on the gro
Am 05.03.2014 09:43, schrieb Markus Armbruster:
> Kevin Wolf writes:
>
>> 'change' is a bit trickier because it involves several low-level actions
>> at once, and device_add is not one of them.
>
> The problem is that it can run while a device model is attached.
What exactly is the problem here
Hi,
> I can't see why QMP commands would ever want to create in state NEEDKEY.
> We could easily avoid it there: give QMP commands creating
> BlockDriverStates an optional password parameter, fail the command if
> the BDS is encrypted and the password parameter is missing.
Fully agree.
The cha
Il 05/03/2014 09:43, Markus Armbruster ha scritto:
Or we can do our users a favor and kill support for encrypted images
dead (except in qemu-img, of course). Revive when we have encryption
that actually works, both in the safety and security sense.
I think this is okay, since the patch should
Il 05/03/2014 09:24, Markus Armbruster ha scritto:
Paolo Bonzini writes:
Il 28/02/2014 23:08, Eric Blake ha scritto:
Use the fact that we are calling the next release "2.0" to actually kill
qemu disk encryption as a horribly botched feature, on the grounds that
we are doing users a favor by n
Kevin Wolf writes:
> Am 28.02.2014 um 22:01 hat Markus Armbruster geschrieben:
>> Questions:
>>
>> 1. Should we protect guests from state NEEDKEY?
>
> Yes. An image in state NEEDKEY isn't fully initialised, so we should
> make sure that it isn't used.
Consensus.
>> 2. If yes, how?
>>
>>Pa
Paolo Bonzini writes:
> Il 28/02/2014 23:08, Eric Blake ha scritto:
>> Use the fact that we are calling the next release "2.0" to actually kill
>> qemu disk encryption as a horribly botched feature, on the grounds that
>> we are doing users a favor by not letting them use broken encryption?
>
> O
Eric Blake writes:
> On 02/28/2014 02:01 PM, Markus Armbruster wrote:
>> The encrypted images Saturday afternoon hack is a gift that keeps on
>> giving. I wish we could rip it out and bury it deep. Or that I could
>> continue to ignore it. Unfortunately, it looks like I need to touch it
>> to
Am 28.02.2014 um 22:01 hat Markus Armbruster geschrieben:
> Questions:
>
> 1. Should we protect guests from state NEEDKEY?
Yes. An image in state NEEDKEY isn't fully initialised, so we should
make sure that it isn't used.
> 2. If yes, how?
>
>Pause the guest when something enters state NEED
Il 28/02/2014 23:08, Eric Blake ha scritto:
Use the fact that we are calling the next release "2.0" to actually kill
qemu disk encryption as a horribly botched feature, on the grounds that
we are doing users a favor by not letting them use broken encryption?
Only for qemu, of course---qemu-img
On 02/28/2014 02:01 PM, Markus Armbruster wrote:
> The encrypted images Saturday afternoon hack is a gift that keeps on
> giving. I wish we could rip it out and bury it deep. Or that I could
> continue to ignore it. Unfortunately, it looks like I need to touch it
> to clean up error propagation
The encrypted images Saturday afternoon hack is a gift that keeps on
giving. I wish we could rip it out and bury it deep. Or that I could
continue to ignore it. Unfortunately, it looks like I need to touch it
to clean up error propagation in the monitor. So here goes.
A naive user might expect
17 matches
Mail list logo
