aboutsummaryrefslogtreecommitdiffstats
path: root/tools/libxc/xc_dom.h
diff options
context:
space:
mode:
authorIan Jackson <Ian.Jackson@eu.citrix.com>2012-10-26 16:09:29 +0100
committerIan Jackson <Ian.Jackson@eu.citrix.com>2012-10-26 16:09:29 +0100
commit127c78b8b7615b2e895a879792f4b0b825a02a81 (patch)
tree067b72c5020d4bd43f7416414f8bffecdb7a2e2e /tools/libxc/xc_dom.h
parentce015753b6b8d00b935a8f75e17cf439ef80c65b (diff)
downloadxen-127c78b8b7615b2e895a879792f4b0b825a02a81.tar.gz
xen-127c78b8b7615b2e895a879792f4b0b825a02a81.tar.bz2
xen-127c78b8b7615b2e895a879792f4b0b825a02a81.zip
libxc: builder: limit maximum size of kernel/ramdisk.
Allowing user supplied kernels of arbitrary sizes, especially during decompression, can swallow up dom0 memory leading to either virtual address space exhaustion in the builder process or allocation failures/OOM killing of both toolstack and unrelated processes. We disable these checks when building in a stub domain for pvgrub since this uses the guest's own memory and is isolated. Decompression of gzip compressed kernels and ramdisks has been safe since 14954:58205257517d (Xen 3.1.0 onwards). This is XSA-25 / CVE-2012-4544. Also make explicit checks for buffer overflows in various decompression routines. These were already ruled out due to other properties of the code but check them as a belt-and-braces measure. Signed-off-by: Ian Campbell <ian.campbell@citrix.com> Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
Diffstat (limited to 'tools/libxc/xc_dom.h')
-rw-r--r--tools/libxc/xc_dom.h23
1 files changed, 22 insertions, 1 deletions
diff --git a/tools/libxc/xc_dom.h b/tools/libxc/xc_dom.h
index 3cd6dae6d6..eccc516c2c 100644
--- a/tools/libxc/xc_dom.h
+++ b/tools/libxc/xc_dom.h
@@ -55,6 +55,9 @@ struct xc_dom_image {
void *ramdisk_blob;
size_t ramdisk_size;
+ size_t max_kernel_size;
+ size_t max_ramdisk_size;
+
/* arguments and parameters */
char *cmdline;
uint32_t f_requested[XENFEAT_NR_SUBMAPS];
@@ -194,6 +197,23 @@ void xc_dom_release_phys(struct xc_dom_image *dom);
void xc_dom_release(struct xc_dom_image *dom);
int xc_dom_mem_init(struct xc_dom_image *dom, unsigned int mem_mb);
+/* Set this larger if you have enormous ramdisks/kernels. Note that
+ * you should trust all kernels not to be maliciously large (e.g. to
+ * exhaust all dom0 memory) if you do this (see CVE-2012-4544 /
+ * XSA-25). You can also set the default independently for
+ * ramdisks/kernels in xc_dom_allocate() or call
+ * xc_dom_{kernel,ramdisk}_max_size.
+ */
+#ifndef XC_DOM_DECOMPRESS_MAX
+#define XC_DOM_DECOMPRESS_MAX (1024*1024*1024) /* 1GB */
+#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);
int xc_dom_do_gunzip(xc_interface *xch,
@@ -254,7 +274,8 @@ void xc_dom_log_memory_footprint(struct xc_dom_image *dom);
void *xc_dom_malloc(struct xc_dom_image *dom, size_t size);
void *xc_dom_malloc_page_aligned(struct xc_dom_image *dom, size_t size);
void *xc_dom_malloc_filemap(struct xc_dom_image *dom,
- const char *filename, size_t * size);
+ const char *filename, size_t * size,
+ const size_t max_size);
char *xc_dom_strdup(struct xc_dom_image *dom, const char *str);
/* --- alloc memory pool ------------------------------------------- */