[libvirt] [PATCH] rpc: message related sizes enlarged
From: Daniel Hansel <daniel.hansel@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@linux.vnet.ibm.com> Signed-off-by: Viktor Mihajlovski <mihajlov@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
On 22.04.2013 16:22, Viktor Mihajlovski wrote:
From: Daniel Hansel <daniel.hansel@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@linux.vnet.ibm.com> Signed-off-by: Viktor Mihajlovski <mihajlov@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
On Mon, Apr 22, 2013 at 04:22:26PM +0200, Viktor Mihajlovski wrote:
From: Daniel Hansel <daniel.hansel@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 :|
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
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 :|
participants (3)
-
Daniel P. Berrange -
Michal Privoznik -
Viktor Mihajlovski