|
[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
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |