Andrew Cooper
2013-Jan-28 11:44 UTC
[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
Ian Campbell
2013-Jan-28 11:50 UTC
Re: [PATCH v2] xenguest: Alter xsa-25 decompression limit prototypes
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.
Andrew Cooper
2013-Jan-28 11:57 UTC
Re: [PATCH v2] xenguest: Alter xsa-25 decompression limit prototypes
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
Ian Campbell
2013-Jan-28 12:05 UTC
Re: [PATCH v2] xenguest: Alter xsa-25 decompression limit prototypes
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.
Andrew Cooper
2013-Jan-28 12:52 UTC
Re: [PATCH v2] xenguest: Alter xsa-25 decompression limit prototypes
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