Re: [Xen-devel] [PATCH] libxl: make sure buffer is null-terminated in libxl_read_file_contents [and 3 more messages]

[Ian Jackson <ian.jackson@xxxxxxxxxx>]

Taking things in order from most salient to least salient:

Robin Lee writes ("Re: [Xen-devel] [PATCH] libxl: make sure buffer is 
null-terminated in libxl_read_file_contents"):
> In my situation, the json file is created with external program and
> contains just "{}\n" and not trailing 0.

I just want to be sure I understand correctly.  You are creating the
libxl domain config userdata json yourself, and stuffing it into
/var/lib/xen ?  That file is internal to libxl and doing that is,
obviously, not supported.

I think, though, that what "not supported" means is that the format
and storage location and so on may change, and that you are on your
own if it does.

However, I don't think it means that if you discover bugs or
infelicities, we shouldn't fix them.  So:

Wei Liu writes ("Re: [Xen-devel] [PATCH] libxl: make sure buffer is 
null-terminated in libxl_read_file_contents"):
> Alright. In that case please append 0 to the file you created.

I don't really agree that this is the right answer.  Thanks, to Robin,
for bringing this to our attention.

It is clearly bizarre that this file, which in the design is supposed
to be json, (i) happens to contain a trailing nul (ii) which is
necessary for correct operation.

We cannot fix (i) without invalidating old files, which we don't want
to do.  But we should fix (ii).

I am inclined to think that something along the lines of the original
patch is the way to do that.  Although, this extra nul byte should be
documented in the API comment then.

Also, we should identify where the additional nul byte is coming
from.  While we can't just delete that, we should put a comment in
saying that the off-by-one error is deliberate.

Wei Liu writes ("Re: [Xen-devel] [PATCH] libxl: make sure buffer is 
null-terminated in libxl_read_file_contents"):
> BTW if you're using XenServer you probably should use XAPI to manipulate
> guests instead.

I don't entirely agree with this either.  Obviously mixing and
matching like this is not a supported configuration, in the sense that
you don't get any stability guarantees.

But in practice it is likely to work (provided XAPI does not get
confused) and it seems like part of a reasonable transition strategy
for a complicated system to make more use of libxl.

Thanks,
Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel