On (Fri) 01 Mar 2013 [10:51:33], Paolo Bonzini wrote:
> Il 01/03/2013 01:36, Eric Blake ha scritto:
> > For fd passing to work, we have to use qemu_open() instead of raw
> > open(). Is there any way to enforce that all files being opened by qemu
> > go through the appropriate qemu_open() wrapper?
On 03/02/2013 04:23 AM, Paolo Bonzini wrote:
> Il 02/03/2013 04:13, Anthony Liguori ha scritto:
>> There is no valid use-case of rng-random other than using /dev/random.
>> In fact, it was probably a mistake to even allow a filename to be
>> specified because it lets people do silly things (like /d
On 03/04/2013 03:24 PM, Anthony Liguori wrote:
>> Then libvirt should also make sure that the XML we allow for non-egd
>> virtio-rng is restricted to the two filenames that won't cause a qemu
>> warning, or even modify the XML to not expose a filename in the first
>> place. We haven't released lib
Eric Blake writes:
> [adding libvirt]
>
> On 03/03/2013 02:05 PM, Anthony Liguori wrote:
>> Paolo Bonzini writes:
>>
>>> Il 02/03/2013 04:13, Anthony Liguori ha scritto:
There is no valid use-case of rng-random other than using /dev/random.
In fact, it was probably a mistake to even a
[adding libvirt]
On 03/03/2013 02:05 PM, Anthony Liguori wrote:
> Paolo Bonzini writes:
>
>> Il 02/03/2013 04:13, Anthony Liguori ha scritto:
>>> There is no valid use-case of rng-random other than using /dev/random.
>>> In fact, it was probably a mistake to even allow a filename to be
>>> speci
On 03/01/2013 08:13 PM, Anthony Liguori wrote:
> Eric Blake writes:
>
>> On 03/01/2013 04:59 PM, Anthony Liguori wrote:
>>> I said this when seccomp was first introduced and I'll say it again.
>>> blacklisting open() is a bad idea. DAC and MAC already exist and solve
>>> this problem. We've got
On 03/01/2013 10:34 PM, Stefan Berger wrote:
On 03/01/2013 10:17 PM, Anthony Liguori wrote:
Stefan Berger writes:
On 03/01/2013 06:59 PM, Anthony Liguori wrote:
Eric Blake writes:
On 03/01/2013 04:05 PM, Anthony Liguori wrote:
Eric Blake writes:
On 03/01/2013 02:08 PM, Anthony Liguo
On 03/04/2013 05:29 AM, Daniel P. Berrange wrote:
On Fri, Mar 01, 2013 at 04:14:40PM -0700, Eric Blake wrote:
I understand the reason that fdsets exist (because NFS is stupid and
doesn't support labeling). But we aren't doing dynamic labeling of
/dev/random and I strongly suspect it's not on
On Fri, Mar 01, 2013 at 04:14:40PM -0700, Eric Blake wrote:
> > I understand the reason that fdsets exist (because NFS is stupid and
> > doesn't support labeling). But we aren't doing dynamic labeling of
> > /dev/random and I strongly suspect it's not on NFS anyway.
> >
> > So why are we trying t
On (Fri) 01 Mar 2013 [10:51:33], Paolo Bonzini wrote:
> Il 01/03/2013 01:36, Eric Blake ha scritto:
> > For fd passing to work, we have to use qemu_open() instead of raw
> > open(). Is there any way to enforce that all files being opened by qemu
> > go through the appropriate qemu_open() wrapper?
Stefan Berger writes:
> It depends on what one defends against. If a jail-break succeeds and
> open() is disabled, then that attack surfaces was effectively reduced.
> It's hard to say whether opening files within libvirt could then allow
> new exploits.
Well, in the very least, libvirt is do
Paolo Bonzini writes:
> Il 02/03/2013 04:13, Anthony Liguori ha scritto:
>> There is no valid use-case of rng-random other than using /dev/random.
>> In fact, it was probably a mistake to even allow a filename to be
>> specified because it lets people do silly things (like /dev/urandom).
>>
>> I
Il 02/03/2013 04:13, Anthony Liguori ha scritto:
> There is no valid use-case of rng-random other than using /dev/random.
> In fact, it was probably a mistake to even allow a filename to be
> specified because it lets people do silly things (like /dev/urandom).
>
> If you want anything other than
On 03/01/2013 10:17 PM, Anthony Liguori wrote:
Stefan Berger writes:
On 03/01/2013 06:59 PM, Anthony Liguori wrote:
Eric Blake writes:
On 03/01/2013 04:05 PM, Anthony Liguori wrote:
Eric Blake writes:
On 03/01/2013 02:08 PM, Anthony Liguori wrote:
You can pass chardevs to the egd bac
Stefan Berger writes:
> On 03/01/2013 06:59 PM, Anthony Liguori wrote:
>> Eric Blake writes:
>>
>>> On 03/01/2013 04:05 PM, Anthony Liguori wrote:
Eric Blake writes:
> On 03/01/2013 02:08 PM, Anthony Liguori wrote:
>
You can pass chardevs to the egd backend. It's rea
Eric Blake writes:
> On 03/01/2013 04:59 PM, Anthony Liguori wrote:
>> I said this when seccomp was first introduced and I'll say it again.
>> blacklisting open() is a bad idea. DAC and MAC already exist and solve
>> this problem. We've got filesystem namespaces too.
>
> Let's explore that idea
On 03/01/2013 06:59 PM, Anthony Liguori wrote:
Eric Blake writes:
On 03/01/2013 04:05 PM, Anthony Liguori wrote:
Eric Blake writes:
On 03/01/2013 02:08 PM, Anthony Liguori wrote:
You can pass chardevs to the egd backend. It's really not a good idea
to pass a fd via rng-rangom.
Why not?
On 03/01/2013 04:59 PM, Anthony Liguori wrote:
> I said this when seccomp was first introduced and I'll say it again.
> blacklisting open() is a bad idea. DAC and MAC already exist and solve
> this problem. We've got filesystem namespaces too.
Let's explore that idea a bit further. What happens
Eric Blake writes:
> On 03/01/2013 04:05 PM, Anthony Liguori wrote:
>> Eric Blake writes:
>>
>>> On 03/01/2013 02:08 PM, Anthony Liguori wrote:
>>>
>> You can pass chardevs to the egd backend. It's really not a good idea
>> to pass a fd via rng-rangom.
>>>
>>> Why not? If you are runn
On 03/01/2013 04:05 PM, Anthony Liguori wrote:
> Eric Blake writes:
>
>> On 03/01/2013 02:08 PM, Anthony Liguori wrote:
>>
> You can pass chardevs to the egd backend. It's really not a good idea
> to pass a fd via rng-rangom.
>>
>> Why not? If you are running a single guest, why can't l
Peter Krempa writes:
> On 03/01/13 21:04, Anthony Liguori wrote:
>> Eric Blake writes:
>>
>>> Stefan Berger and I discovered on IRC that virtio-rng is unable to
>>> support fd passing. We attempted:
>>>
>>> qemu-system-x86_64 ... -add-fd set=4,fd=34,opaque=RDONLY:/dev/urandom
>>> -object rng-ra
Eric Blake writes:
> On 03/01/2013 02:08 PM, Anthony Liguori wrote:
>
You can pass chardevs to the egd backend. It's really not a good idea
to pass a fd via rng-rangom.
>
> Why not? If you are running a single guest, why can't libvirt pass that
> one guest an fd instead of making qemu
On 03/01/13 21:04, Anthony Liguori wrote:
Eric Blake writes:
Stefan Berger and I discovered on IRC that virtio-rng is unable to
support fd passing. We attempted:
qemu-system-x86_64 ... -add-fd set=4,fd=34,opaque=RDONLY:/dev/urandom
-object rng-random,id=rng0,filename=/dev/fdset/4 -device
vir
On 03/01/2013 02:08 PM, Anthony Liguori wrote:
>>> You can pass chardevs to the egd backend. It's really not a good idea
>>> to pass a fd via rng-rangom.
Why not? If you are running a single guest, why can't libvirt pass that
one guest an fd instead of making qemu open() the file?
>>
>> Fine,
Stefan Berger writes:
> On 03/01/2013 03:04 PM, Anthony Liguori wrote:
>> Eric Blake writes:
>>
>>> Stefan Berger and I discovered on IRC that virtio-rng is unable to
>>> support fd passing. We attempted:
>>>
>>> qemu-system-x86_64 ... -add-fd set=4,fd=34,opaque=RDONLY:/dev/urandom
>>> -object
Il 01/03/2013 21:13, Stefan Berger ha scritto:
> On 03/01/2013 02:37 PM, H. Peter Anvin wrote:
>> On 02/28/2013 04:36 PM, Eric Blake wrote:
>>> Stefan Berger and I discovered on IRC that virtio-rng is unable to
>>> support fd passing. We attempted:
>>>
>>> qemu-system-x86_64 ... -add-fd
>>> set=4,
On 03/01/2013 03:04 PM, Anthony Liguori wrote:
Eric Blake writes:
Stefan Berger and I discovered on IRC that virtio-rng is unable to
support fd passing. We attempted:
qemu-system-x86_64 ... -add-fd set=4,fd=34,opaque=RDONLY:/dev/urandom
-object rng-random,id=rng0,filename=/dev/fdset/4 -devic
The guest kernel already provides the PRNG itself. We have been over this...
Stefan Berger wrote:
>On 03/01/2013 02:37 PM, H. Peter Anvin wrote:
>> On 02/28/2013 04:36 PM, Eric Blake wrote:
>>> Stefan Berger and I discovered on IRC that virtio-rng is unable to
>>> support fd passing. We attemp
On 03/01/2013 02:37 PM, H. Peter Anvin wrote:
On 02/28/2013 04:36 PM, Eric Blake wrote:
Stefan Berger and I discovered on IRC that virtio-rng is unable to
support fd passing. We attempted:
qemu-system-x86_64 ... -add-fd
set=4,fd=34,opaque=RDONLY:/dev/urandom
^
Eric Blake writes:
> Stefan Berger and I discovered on IRC that virtio-rng is unable to
> support fd passing. We attempted:
>
> qemu-system-x86_64 ... -add-fd set=4,fd=34,opaque=RDONLY:/dev/urandom
> -object rng-random,id=rng0,filename=/dev/fdset/4 -device
> virtio-rng-pci,rng=rng0,bus=pci.0,add
On 02/28/2013 04:36 PM, Eric Blake wrote:
> Stefan Berger and I discovered on IRC that virtio-rng is unable to
> support fd passing. We attempted:
>
> qemu-system-x86_64 ... -add-fd
> set=4,fd=34,opaque=RDONLY:/dev/urandom
> -object rng-random,id=rng0,fil
Il 01/03/2013 01:36, Eric Blake ha scritto:
> For fd passing to work, we have to use qemu_open() instead of raw
> open(). Is there any way to enforce that all files being opened by qemu
> go through the appropriate qemu_open() wrapper?
>
> Meanwhile, we have a quandary on the libvirt side of thin
Stefan Berger and I discovered on IRC that virtio-rng is unable to
support fd passing. We attempted:
qemu-system-x86_64 ... -add-fd set=4,fd=34,opaque=RDONLY:/dev/urandom
-object rng-random,id=rng0,filename=/dev/fdset/4 -device
virtio-rng-pci,rng=rng0,bus=pci.0,addr=0x6
qemu-system-x86_64: -devi
33 matches
Mail list logo
