9:22 a.m.
From: Daniel Hansel <daniel.hansel(a)linux.vnet.ibm.com>
We have seen an issue on s390x platform where domain XMLs larger than 1MB
were used. The define command was finished successfully. The dumpxml command
was not successful (i.e. could not encode message payload).
Enlarged message related sizes (e.g. maximum string size, message size, etc.)
to handle larger system configurations used on s390x platform.
Signed-off-by: Daniel Hansel <daniel.hansel(a)linux.vnet.ibm.com>
Signed-off-by: Viktor Mihajlovski <mihajlov(a)linux.vnet.ibm.com>
---
src/remote/remote_protocol.x | 6 +++---
src/rpc/virnetprotocol.x | 6 +++---
2 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/src/remote/remote_protocol.x b/src/remote/remote_protocol.x
index b957b8e..d492bf3 100644
--- a/src/remote/remote_protocol.x
+++ b/src/remote/remote_protocol.x
@@ -65,7 +65,7 @@
* This is an arbitrary limit designed to stop the decoder from trying
* to allocate unbounded amounts of memory when fed with a bad message.
*/
-const REMOTE_STRING_MAX = 1048576;
+const REMOTE_STRING_MAX = 4194304;
/* A long string, which may NOT be NULL. */
typedef string remote_nonnull_string<REMOTE_STRING_MAX>;
@@ -160,13 +160,13 @@ const REMOTE_DOMAIN_SNAPSHOT_LIST_NAMES_MAX = 1024;
* Note applications need to be aware of this limit and issue multiple
* requests for large amounts of data.
*/
-const REMOTE_DOMAIN_BLOCK_PEEK_BUFFER_MAX = 1048576;
+const REMOTE_DOMAIN_BLOCK_PEEK_BUFFER_MAX = 4194304;
/* Maximum length of a memory peek buffer message.
* Note applications need to be aware of this limit and issue multiple
* requests for large amounts of data.
*/
-const REMOTE_DOMAIN_MEMORY_PEEK_BUFFER_MAX = 1048576;
+const REMOTE_DOMAIN_MEMORY_PEEK_BUFFER_MAX = 4194304;
/*
* Maximum length of a security label list.
diff --git a/src/rpc/virnetprotocol.x b/src/rpc/virnetprotocol.x
index eb2e81d..7d5557c 100644
--- a/src/rpc/virnetprotocol.x
+++ b/src/rpc/virnetprotocol.x
@@ -45,13 +45,13 @@
/*----- Data types. -----*/
/* Maximum total message size (serialised). */
-const VIR_NET_MESSAGE_MAX = 4194304;
+const VIR_NET_MESSAGE_MAX = 16777216;
/* Size of struct virNetMessageHeader (serialised)*/
const VIR_NET_MESSAGE_HEADER_MAX = 24;
/* Size of message payload */
-const VIR_NET_MESSAGE_PAYLOAD_MAX = 4194280;
+const VIR_NET_MESSAGE_PAYLOAD_MAX = 16777192;
/* Size of message length field. Not counted in VIR_NET_MESSAGE_MAX */
const VIR_NET_MESSAGE_LEN_MAX = 4;
@@ -60,7 +60,7 @@ const VIR_NET_MESSAGE_LEN_MAX = 4;
* This is an arbitrary limit designed to stop the decoder from trying
* to allocate unbounded amounts of memory when fed with a bad message.
*/
-const VIR_NET_MESSAGE_STRING_MAX = 1048576;
+const VIR_NET_MESSAGE_STRING_MAX = 4194304;
/* Limit on number of File Descriptors allowed to be
* passed per message
--
1.7.9.5
9:32 a.m.
On 22.04.2013 16:22, Viktor Mihajlovski wrote:
From: Daniel Hansel <daniel.hansel(a)linux.vnet.ibm.com>
We have seen an issue on s390x platform where domain XMLs larger than 1MB
were used. The define command was finished successfully. The dumpxml command
was not successful (i.e. could not encode message payload).
Enlarged message related sizes (e.g. maximum string size, message size, etc.)
to handle larger system configurations used on s390x platform.
Signed-off-by: Daniel Hansel <daniel.hansel(a)linux.vnet.ibm.com>
Signed-off-by: Viktor Mihajlovski <mihajlov(a)linux.vnet.ibm.com>
---
src/remote/remote_protocol.x | 6 +++---
src/rpc/virnetprotocol.x | 6 +++---
2 files changed, 6 insertions(+), 6 deletions(-)
I am not hesitant to take this patch in. However, src/libvirt.c needs
update as well then. See eb635de1. We should tell users in documentation
that we have raised the RPC message limit.
Or even better - should the limit be turned into a config option so
system admins can decide on the most suitable value themselves? On one
hand, we need a bigger messages, obviously. But on the other hand,
libvirt is allocating a message for each connection so an evil user can
do a DOS attack by spoofing message length headers.
Michal
9:34 a.m.
On Mon, Apr 22, 2013 at 04:22:26PM +0200, Viktor Mihajlovski wrote:
From: Daniel Hansel <daniel.hansel(a)linux.vnet.ibm.com>
We have seen an issue on s390x platform where domain XMLs larger than 1MB
were used. The define command was finished successfully. The dumpxml command
was not successful (i.e. could not encode message payload).
Enlarged message related sizes (e.g. maximum string size, message size, etc.)
to handle larger system configurations used on s390x platform.
I'm not against this in general, but before we enlarge this so much
there needs to be some code work to make RPC message encoding more
efficient. Currently virNetMessageEncodeHeader will allocate
VIR_NET_MESSAGE_MAX immediately, regardless of whether the message
being encoded acutally needs so much. The problem is that we can't
tell ahead of time how much space a message needs. We just can't go
on doing this if we're going to have such large max message size.
We need to start with small allocs & grow if we hit the size limit.
Daniel
--
|: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org -o- http://virt-manager.org :|
|: http://autobuild.org -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|
11:18 a.m.
On 04/22/2013 04:34 PM, Daniel P. Berrange wrote:
On Mon, Apr 22, 2013 at 04:22:26PM +0200, Viktor Mihajlovski wrote:
I'm not against this in general, but before we enlarge this so much
there needs to be some code work to make RPC message encoding more
efficient. Currently virNetMessageEncodeHeader will allocate
VIR_NET_MESSAGE_MAX immediately, regardless of whether the message
being encoded acutally needs so much. The problem is that we can't
tell ahead of time how much space a message needs. We just can't go
on doing this if we're going to have such large max message size.
We need to start with small allocs & grow if we hit the size limit.
So
something along the lines of allocating VIR_NET_MESSAGE_INITIAL
bytes, maybe well below 1M, and then bumping it in the
EncodePayloadxxx calls if required. Do you foresee any pitfalls
one should consider?
Daniel
--
Mit freundlichen Grüßen/Kind Regards
Viktor Mihajlovski
IBM Deutschland Research & Development GmbH
Vorsitzender des Aufsichtsrats: Martina Köderitz
Geschäftsführung: Dirk Wittkopp
Sitz der Gesellschaft: Böblingen
Registergericht: Amtsgericht Stuttgart, HRB 243294
11:39 a.m.
On Mon, Apr 22, 2013 at 06:18:04PM +0200, Viktor Mihajlovski wrote:
On 04/22/2013 04:34 PM, Daniel P. Berrange wrote:
>On Mon, Apr 22, 2013 at 04:22:26PM +0200, Viktor Mihajlovski wrote:
>I'm not against this in general, but before we enlarge this so much
>there needs to be some code work to make RPC message encoding more
>efficient. Currently virNetMessageEncodeHeader will allocate
>VIR_NET_MESSAGE_MAX immediately, regardless of whether the message
>being encoded acutally needs so much. The problem is that we can't
>tell ahead of time how much space a message needs. We just can't go
>on doing this if we're going to have such large max message size.
>We need to start with small allocs & grow if we hit the size limit.
So something along the lines of allocating VIR_NET_MESSAGE_INITIAL
bytes, maybe well below 1M, and then bumping it in the
EncodePayloadxxx calls if required. Do you foresee any pitfalls
one should consider?
We have an ever increasing variability in RPC message size - some of
them will remain absolutely tiny - 24 bytes in size, while others can
be huge. Deciding on the optimal initial allocation size is a tradeoff
between the overheads of frequently re-alloc'ing to enlarge the buffer,
vs the overhead of allocting too much memory and/or calling memset()
on the buffers.
I'd suggest an initial size of just a perhaps as small as a few 10's
of KB ? Then do a loop doubling allocation each time until it hits
the hard limit. In cases where we even up triggering the re-alloc
loop many times, we'll presumably be on large hardware with many
many VMs, so the overhead of the re-allocs will be dwarved by all
the other activity on the machine.
Daniel
--
|: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org -o- http://virt-manager.org :|
|: http://autobuild.org -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|
4232
days inactive
4232
days old
4 comments
3 participants
participants (3)
-
Daniel P. Berrange -
Michal Privoznik -
Viktor Mihajlovski