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

[Wei Liu <wei.liu2@xxxxxxxxxx>]

On Thu, Jun 28, 2018 at 11:24:42AM +0100, Ian Jackson wrote:
> 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).
> 

We can safely remove the trailing nul if libxl API makes sure a buffer
is nul-terminated. Old files will still work with new library. New files
won't work with old library -- but we don't support that.

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

What off-by-one error?

Wei.

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