Am 27.07.2010 20:25, schrieb Anthony Liguori:
> On 07/27/2010 12:43 PM, Anthony PERARD wrote:
>> Anthony Liguori wrote:
>>> On 07/27/2010 12:01 PM, Anthony PERARD wrote:
Anthony Liguori wrote:
> CVE-2008-2004 described a vulnerability in QEMU whereas a malicious
> user could
> tri
On 07/27/2010 12:43 PM, Anthony PERARD wrote:
Anthony Liguori wrote:
On 07/27/2010 12:01 PM, Anthony PERARD wrote:
Anthony Liguori wrote:
CVE-2008-2004 described a vulnerability in QEMU whereas a malicious
user could
trick the block probing code into accessing arbitrary files in a
guest. To
Anthony Liguori wrote:
On 07/27/2010 12:01 PM, Anthony PERARD wrote:
Anthony Liguori wrote:
CVE-2008-2004 described a vulnerability in QEMU whereas a malicious
user could
trick the block probing code into accessing arbitrary files in a
guest. To
mitigate this, we added an explicit format para
On 07/27/2010 12:01 PM, Anthony PERARD wrote:
Anthony Liguori wrote:
CVE-2008-2004 described a vulnerability in QEMU whereas a malicious
user could
trick the block probing code into accessing arbitrary files in a
guest. To
mitigate this, we added an explicit format parameter to -drive which
d
Anthony Liguori wrote:
CVE-2008-2004 described a vulnerability in QEMU whereas a malicious user could
trick the block probing code into accessing arbitrary files in a guest. To
mitigate this, we added an explicit format parameter to -drive which disabling
block probing.
Fast forward to today, a
Anthony Liguori writes:
> On 07/15/2010 10:19 AM, Markus Armbruster wrote:
>> Anthony Liguori writes:
>>
>>
>>> On 07/14/2010 01:43 PM, Christoph Hellwig wrote:
>>>
Err, strong NACK. Please don't start messing with the contents of the
data plane, we're getting into real trou
Am 16.07.2010 18:16, schrieb Anthony Liguori:
> On 07/16/2010 11:06 AM, Markus Armbruster wrote:
>> Anthony Liguori writes:
>>> To accomodate current use-cases with raw, let's introduce a new format
>>> called "probed_raw". probed_raw's semantics will be the following:
>>>
>>> The signature of a
On 07/16/2010 11:06 AM, Markus Armbruster wrote:
Anthony Liguori writes:
On 07/15/2010 10:19 AM, Markus Armbruster wrote:
Anthony Liguori writes:
On 07/14/2010 01:43 PM, Christoph Hellwig wrote:
Err, strong NACK. Please don't start messing with the contents
On Fri, Jul 16, 2010 at 1:55 PM, Stefan Hajnoczi wrote:
> On Thu, Jul 15, 2010 at 5:20 PM, Anthony Liguori
> wrote:
>> On 07/15/2010 10:19 AM, Markus Armbruster wrote:
>>>
>>> Anthony Liguori writes:
>>>
>>>
On 07/14/2010 01:43 PM, Christoph Hellwig wrote:
>
> Err, strong
On Thu, Jul 15, 2010 at 5:20 PM, Anthony Liguori wrote:
> On 07/15/2010 10:19 AM, Markus Armbruster wrote:
>>
>> Anthony Liguori writes:
>>
>>
>>>
>>> On 07/14/2010 01:43 PM, Christoph Hellwig wrote:
>>>
Err, strong NACK. Please don't start messing with the contents of the
data pl
Am 15.07.2010 19:51, schrieb Anthony Liguori:
> On 07/15/2010 12:10 PM, Kevin Wolf wrote:
>> Am 15.07.2010 18:20, schrieb Anthony Liguori:
>>
>>> I have another idea that I hope will solve the problem in a more
>>> complete way. The fundamental issue is that it's impossible to probe
>>> raw im
On 07/15/2010 12:10 PM, Kevin Wolf wrote:
Am 15.07.2010 18:20, schrieb Anthony Liguori:
I have another idea that I hope will solve the problem in a more
complete way. The fundamental issue is that it's impossible to probe
raw images reliably. We can probe qcow2, vmdk, etc but not raw.
So,
Am 15.07.2010 18:20, schrieb Anthony Liguori:
> I have another idea that I hope will solve the problem in a more
> complete way. The fundamental issue is that it's impossible to probe
> raw images reliably. We can probe qcow2, vmdk, etc but not raw.
>
> So, let's do the following: have raw_pro
On 07/15/2010 10:19 AM, Markus Armbruster wrote:
Anthony Liguori writes:
On 07/14/2010 01:43 PM, Christoph Hellwig wrote:
Err, strong NACK. Please don't start messing with the contents of the
data plane, we're getting into real trouble there. It's perfectly
valid for a guest to cr
Anthony Liguori writes:
> On 07/14/2010 01:43 PM, Christoph Hellwig wrote:
>> Err, strong NACK. Please don't start messing with the contents of the
>> data plane, we're getting into real trouble there. It's perfectly
>> valid for a guest to create an image inside an image, and with hardware
>>
On Thu, Jul 15, 2010 at 1:57 PM, Anthony Liguori
wrote:
> On 07/15/2010 04:10 AM, Stefan Hajnoczi wrote:
>>
>> I have mixed feelings about this approach. It has good usability
>> because legitimate users are unaffected, but adding a check into the
>> I/O path is unfortunate from a clean code pers
Am 15.07.2010 14:57, schrieb Anthony Liguori:
> On 07/15/2010 04:10 AM, Stefan Hajnoczi wrote:
>> I think there are actually two issues here:
>>
>> 1. Confusing QEMU so it sees an image with a different format than expected.
>>
>> This is important because it's unexpected behavior for a user who pu
On 07/15/2010 04:10 AM, Stefan Hajnoczi wrote:
I have mixed feelings about this approach. It has good usability
because legitimate users are unaffected, but adding a check into the
I/O path is unfortunate from a clean code perspective.
Management stacks that don't explicitly set format= today a
CVE-2008-2004 described a vulnerability in QEMU whereas a malicious user could
trick the block probing code into accessing arbitrary files in a guest. To
mitigate this, we added an explicit format parameter to -drive which disabling
block probing.
Fast forward to today, and the vast majority of u
On 07/15/2010 04:20 AM, Daniel P. Berrange wrote:
On Wed, Jul 14, 2010 at 01:50:02PM -0500, Anthony Liguori wrote:
On 07/14/2010 01:43 PM, Christoph Hellwig wrote:
Err, strong NACK. Please don't start messing with the contents of the
data plane, we're getting into real trouble there.
On Wed, Jul 14, 2010 at 01:50:02PM -0500, Anthony Liguori wrote:
> On 07/14/2010 01:43 PM, Christoph Hellwig wrote:
> >Err, strong NACK. Please don't start messing with the contents of the
> >data plane, we're getting into real trouble there. It's perfectly
> >valid for a guest to create an image
On Thu, Jul 15, 2010 at 9:09 AM, Kevin Wolf wrote:
> Am 14.07.2010 20:43, schrieb Christoph Hellwig:
>> Err, strong NACK. Please don't start messing with the contents of the
>> data plane, we're getting into real trouble there. It's perfectly
>> valid for a guest to create an image inside an ima
Am 14.07.2010 20:43, schrieb Christoph Hellwig:
> Err, strong NACK. Please don't start messing with the contents of the
> data plane, we're getting into real trouble there. It's perfectly
> valid for a guest to create an image inside an image, and with hardware
> support for nested virtualization
On 07/14/2010 01:54 PM, Aurelien Jarno wrote:
On Wed, Jul 14, 2010 at 08:43:11PM +0200, Christoph Hellwig wrote:
Err, strong NACK. Please don't start messing with the contents of the
data plane, we're getting into real trouble there. It's perfectly
valid for a guest to create an image insi
On Wed, Jul 14, 2010 at 08:43:11PM +0200, Christoph Hellwig wrote:
> Err, strong NACK. Please don't start messing with the contents of the
> data plane, we're getting into real trouble there. It's perfectly
> valid for a guest to create an image inside an image, and with hardware
> support for ne
On 07/14/2010 01:43 PM, Christoph Hellwig wrote:
Err, strong NACK. Please don't start messing with the contents of the
data plane, we're getting into real trouble there. It's perfectly
valid for a guest to create an image inside an image, and with hardware
support for nested virtualization I gu
On 07/14/2010 01:43 PM, Christoph Hellwig wrote:
Err, strong NACK. Please don't start messing with the contents of the
data plane, we're getting into real trouble there. It's perfectly
valid for a guest to create an image inside an image, and with hardware
support for nested virtualization I gu
Err, strong NACK. Please don't start messing with the contents of the
data plane, we're getting into real trouble there. It's perfectly
valid for a guest to create an image inside an image, and with hardware
support for nested virtualization I guess this use case will become
rather common, just a
CVE-2008-2004 described a vulnerability in QEMU whereas a malicious user could
trick the block probing code into accessing arbitrary files in a guest. To
mitigate this, we added an explicit format parameter to -drive which disabling
block probing.
Fast forward to today, and the vast majority of u
CVE-2008-2004 described a vulnerability in QEMU whereas a malicious user could
trick the block probing code into accessing arbitrary files in a guest. To
mitigate this, we added an explicit format parameter to -drive which disabling
block probing.
Fast forward to today, and the vast majority of u
30 matches
Mail list logo
