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

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

[Christian Lindig]

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


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.

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?

— Christian


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

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

[Ian Jackson]

(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@lists.xen.org
https://lists.xen.org/xen-devel

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

[Wei Liu]

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@lists.xen.org
https://lists.xen.org/xen-devel