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

[Xen-devel] OCaml xenstore: max value size is configure to be 2048 bytes - consistent with C xenstore?



(dropping Lars; CCing MAINTAINERs for affected areas.)

Christian Lindig writes ("OCaml xenstore: max value size is configure to be 
2048 bytes - consistent with C xenstore?"):
> We recently had a case where XenServer installation showed errors because the 
> data stored in OCaml xenstore exceeded 2048 bytes:
> 
> [root@dt87 tmp]# xenstore-write /local/domain/1/foo $(cat /dev/zero | tr '\0' 
> X | dd bs=1 count=2048)
> 2048+0 records in
> 2048+0 records out
> 2048 bytes (2.0 kB) copied, 0.00743674 s, 275 kB/s
> [root@dt87 tmp]# xenstore-write /local/domain/1/foo $(cat /dev/zero | tr '\0' 
> X | dd bs=1 count=2049)
> 2049+0 records in
> 2049+0 records out
> 2049 bytes (2.0 kB) copied, 0.00714459 s, 287 kB/s
> xenstore-write: could not write path /local/domain/1/foo

(xenstore-write is erroneously failing to print errno here, but code
inspection shows that it would be E2BIG.)

> This limit is configured in quota-maxsize:
> 
> https://github.com/mirage/xen/blob/master/tools/ocaml/xenstored/oxenstored.conf.in#L50
> 
> This could be a surprise because in quota.ml it is initialised to 4096 and 
> later reset when the config file is read.

That's quite odd.

> https://github.com/mirage/xen/blob/master/tools/ocaml/xenstored/quota.ml#L24
> 
> My questions: is this behaviour consistent with the C xenstore implementation 
> and if not, should this be documented or changed? Should the OCaml 
> implementation made more consistent by using the 2048 for the initial value?

It's not consistent.  The C implementation does not have this limit.

It has these limits, though:

 4096 bytes of total command payload (ie length of a command
      or response, in the ring, excluding the ring header)
 3072 bytes absolute pathname
 2048 bytes relative pathname

This seems like it would allow a guest to create a data node which
could not be updated by the toolstack domain - because the guest could
use a relative path, but the toolstack domain would have to use an
absolute path.  (It can be read by the toolstack domain because when
reading, the pathname does not need to be specified in the reply; and
of course it can easily be deleted.  So I don't think there are
security problems here.)

I think we should probably impose a limit in the C xenstored which
prevents such a situation.

I'm not sure that the value of 2048 is right, though.  A guest could
write a 2048-byte data item at a 2048-byte relative path, and this
would have the same problem.

Thinking about this some more I suggest we:
  * reduce the relative pathname limit to 1536 bytes
  * impose a 2048-byte per-node-data length limit in the C xenstored
  * change the compiled-in 4096-byte per-node-data limit in the
    Ocaml xenstored to 2048 bytes

What do people think ?  Whatever we do this should probably be
post-4.9.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.