Xen devel - Jan 2013 - [PATCH v2] xenguest: Alter xsa-25 decompression limit prototypes

To allow xenguest consumers to make use of the extra protection added as a
result of xsa-25.

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>

---
Changes since v1:
 * Remove prototypes from xc_dom.h to remove duplication

diff -r 5af4f2ab06f3 -r 75aafcd809a7 tools/libxc/xc_dom.h
--- a/tools/libxc/xc_dom.h
+++ b/tools/libxc/xc_dom.h
@@ -209,10 +209,7 @@ int xc_dom_mem_init(struct xc_dom_image 
 #endif
 
 int xc_dom_kernel_check_size(struct xc_dom_image *dom, size_t sz);
-int xc_dom_kernel_max_size(struct xc_dom_image *dom, size_t sz);
-
 int xc_dom_ramdisk_check_size(struct xc_dom_image *dom, size_t sz);
-int xc_dom_ramdisk_max_size(struct xc_dom_image *dom, size_t sz);
 
 size_t xc_dom_check_gzip(xc_interface *xch,
                      void *blob, size_t ziplen);
diff -r 5af4f2ab06f3 -r 75aafcd809a7 tools/libxc/xenguest.h
--- a/tools/libxc/xenguest.h
+++ b/tools/libxc/xenguest.h
@@ -177,6 +177,10 @@ int xc_dom_linux_build(xc_interface *xch
 		       unsigned int console_evtchn,
 		       unsigned long *console_mfn);
 
+#define XENCTRL_HAS_DECOMPRESS_LIMITS
+int xc_dom_kernel_max_size(struct xc_dom_image *dom, size_t sz);
+int xc_dom_ramdisk_max_size(struct xc_dom_image *dom, size_t sz);
+
 /**
  * This function will create a domain for a paravirtualized Linux
  * using buffers for kernel and initrd

On Mon, 2013-01-28 at 11:44 +0000, Andrew Cooper wrote:
> To allow xenguest consumers to make use of the extra protection added as a
> result of xsa-25.
> 
> Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
> 
> ---
> Changes since v1:
>  * Remove prototypes from xc_dom.h to remove duplication
> 
> diff -r 5af4f2ab06f3 -r 75aafcd809a7 tools/libxc/xc_dom.h
> --- a/tools/libxc/xc_dom.h
> +++ b/tools/libxc/xc_dom.h
> @@ -209,10 +209,7 @@ int xc_dom_mem_init(struct xc_dom_image 
>  #endif
>  
>  int xc_dom_kernel_check_size(struct xc_dom_image *dom, size_t sz);
> -int xc_dom_kernel_max_size(struct xc_dom_image *dom, size_t sz);
> -
>  int xc_dom_ramdisk_check_size(struct xc_dom_image *dom, size_t sz);
> -int xc_dom_ramdisk_max_size(struct xc_dom_image *dom, size_t sz);
>  
>  size_t xc_dom_check_gzip(xc_interface *xch,
>                       void *blob, size_t ziplen);
> diff -r 5af4f2ab06f3 -r 75aafcd809a7 tools/libxc/xenguest.h
> --- a/tools/libxc/xenguest.h
> +++ b/tools/libxc/xenguest.h
> @@ -177,6 +177,10 @@ int xc_dom_linux_build(xc_interface *xch
>  		       unsigned int console_evtchn,
>  		       unsigned long *console_mfn);
>  
> +#define XENCTRL_HAS_DECOMPRESS_LIMITS
> +int xc_dom_kernel_max_size(struct xc_dom_image *dom, size_t sz);
> +int xc_dom_ramdisk_max_size(struct xc_dom_image *dom, size_t sz);
Looking at this a bit closer, do you know where a utility which only
includes xenguest.h is getting the necessary struct xc_dom_image *
handle from? None of the functions in xenguest.h seem to return it and
the only functions I can find which do are in xc_dom.h...

This seems to be true for the two existing functions in xenguest.h which
take such a handle as well.

The only in tree caller seems to be the Python bindings, and they just
include xc_dom.h. Is there some reason why the ocaml tools can''t just
do
this?

Ian.

On 28/01/13 11:50, Ian Campbell wrote:
> On Mon, 2013-01-28 at 11:44 +0000, Andrew Cooper wrote:
>> To allow xenguest consumers to make use of the extra protection added
as a
>> result of xsa-25.
>>
>> Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
>>
>> ---
>> Changes since v1:
>>  * Remove prototypes from xc_dom.h to remove duplication
>>
>> diff -r 5af4f2ab06f3 -r 75aafcd809a7 tools/libxc/xc_dom.h
>> --- a/tools/libxc/xc_dom.h
>> +++ b/tools/libxc/xc_dom.h
>> @@ -209,10 +209,7 @@ int xc_dom_mem_init(struct xc_dom_image 
>>  #endif
>>  
>>  int xc_dom_kernel_check_size(struct xc_dom_image *dom, size_t sz);
>> -int xc_dom_kernel_max_size(struct xc_dom_image *dom, size_t sz);
>> -
>>  int xc_dom_ramdisk_check_size(struct xc_dom_image *dom, size_t sz);
>> -int xc_dom_ramdisk_max_size(struct xc_dom_image *dom, size_t sz);
>>  
>>  size_t xc_dom_check_gzip(xc_interface *xch,
>>                       void *blob, size_t ziplen);
>> diff -r 5af4f2ab06f3 -r 75aafcd809a7 tools/libxc/xenguest.h
>> --- a/tools/libxc/xenguest.h
>> +++ b/tools/libxc/xenguest.h
>> @@ -177,6 +177,10 @@ int xc_dom_linux_build(xc_interface *xch
>>  		       unsigned int console_evtchn,
>>  		       unsigned long *console_mfn);
>>  
>> +#define XENCTRL_HAS_DECOMPRESS_LIMITS
>> +int xc_dom_kernel_max_size(struct xc_dom_image *dom, size_t sz);
>> +int xc_dom_ramdisk_max_size(struct xc_dom_image *dom, size_t sz);
> Looking at this a bit closer, do you know where a utility which only
> includes xenguest.h is getting the necessary struct xc_dom_image *
> handle from? None of the functions in xenguest.h seem to return it and
> the only functions I can find which do are in xc_dom.h...
>
> This seems to be true for the two existing functions in xenguest.h which
> take such a handle as well.
>
> The only in tree caller seems to be the Python bindings, and they just
> include xc_dom.h. Is there some reason why the ocaml tools can''t
just do
> this?
>
> Ian.
>
The immediate preceeding function, xc_dom_linux_build returns a struct
xc_dom_image * as its second parameter, to allow the user of xenguest to
manage the structure (in so far as it can be managed without the full
declaration).

~Andrew

On Mon, 2013-01-28 at 11:57 +0000, Andrew Cooper wrote:
> The immediate preceeding function, xc_dom_linux_build returns a struct
> xc_dom_image * as its second parameter,
Does it?

Looking at the only caller (the python bindings) I can see that the dom
paramter is an input parameter to that function and was previously
allocated via xc_dom_allocate. Looking at the implementation of
xc_domain_linux_build confirms this.

Ian.

On 28/01/13 12:05, Ian Campbell wrote:
> On Mon, 2013-01-28 at 11:57 +0000, Andrew Cooper wrote:
>
>> The immediate preceeding function, xc_dom_linux_build returns a struct
>> xc_dom_image * as its second parameter,
> Does it?
>
> Looking at the only caller (the python bindings) I can see that the dom
> paramter is an input parameter to that function and was previously
> allocated via xc_dom_allocate. Looking at the implementation of
> xc_domain_linux_build confirms this.
>
> Ian.
>
Ok - this is turning into far more of a rats nest than I originally thought.

Please ignore the patch while I apply some sanity to our code.

~Andrew