qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH v7 RFC] block/vxhs: Initial commit to add Verita


From: Stefan Hajnoczi
Subject: Re: [Qemu-devel] [PATCH v7 RFC] block/vxhs: Initial commit to add Veritas HyperScale VxHS block device support
Date: Wed, 16 Nov 2016 08:12:41 +0000

On Tue, Nov 15, 2016 at 10:38 PM, ashish mittal <address@hidden> wrote:
> On Wed, Sep 28, 2016 at 2:45 PM, Stefan Hajnoczi <address@hidden> wrote:
>> On Tue, Sep 27, 2016 at 09:09:49PM -0700, Ashish Mittal wrote:
>> 5.
>> I don't see any endianness handling or portable alignment of struct
>> fields in the network protocol code.  Binary network protocols need to
>> take care of these issue for portability.  This means libqnio compiled
>> for different architectures will not work.  Do you plan to support any
>> other architectures besides x86?
>>
>
> No, we support only x86 and do not plan to support any other arch.
> Please let me know if this necessitates any changes to the configure
> script.

I think no change to ./configure is necessary.  The library will only
ship on x86 so other platforms will never attempt to compile the code.

>> 6.
>> The networking code doesn't look robust: kvset uses assert() on input
>> from the network so the other side of the connection could cause SIGABRT
>> (coredump), the client uses the msg pointer as the cookie for the
>> response packet so the server can easily crash the client by sending a
>> bogus cookie value, etc.  Even on the client side these things are
>> troublesome but on a server they are guaranteed security issues.  I
>> didn't look into it deeply.  Please audit the code.
>>
>
> By design, our solution on OpenStack platform uses a closed set of
> nodes communicating on dedicated networks. VxHS servers on all the
> nodes are on a dedicated network. Clients (qemu) connects to these
> only after reading the server IP from the XML (read by libvirt). The
> XML cannot be modified without proper access. Therefore, IMO this
> problem would be  relevant only if someone were to use qnio as a
> generic mode of communication/data transfer, but for our use-case, we
> will not run into this problem. Is this explanation acceptable?

No.  The trust model is that the guest is untrusted and in the worst
case may gain code execution in QEMU due to security bugs.

You are assuming block/vxhs.c and libqnio are trusted but that
assumption violates the trust model.

In other words:
1. Guest exploits a security hole inside QEMU and gains code execution
on the host.
2. Guest uses VxHS client file descriptor on host to send a malicious
packet to VxHS server.
3. VxHS server is compromised by guest.
4. Compromised VxHS server sends malicious packets to all other
connected clients.
5. All clients have been compromised.

This means both the VxHS client and server must be robust.  They have
to validate inputs to avoid buffer overflows, assertion failures,
infinite loops, etc.

Stefan



reply via email to

[Prev in Thread] Current Thread [Next in Thread]