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

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



On Thu, Apr 27, 2017 at 03:42:09PM +0100, Ian Jackson wrote:
> (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.
> 

The suggestions make sense. And I agree it is post-4.9 material.

We.

> 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®.