From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrew Cooper Subject: Re: [PATCH] libxc: remove most of tools/libxc/xc_dom_compat_linux.c Date: Thu, 22 Oct 2015 16:51:31 +0100 Message-ID: <56290603.3010808@citrix.com> References: <1444131327-22000-1-git-send-email-jgross@suse.com> <5613C400.4040209@citrix.com> <20151006125858.GB29124@zion.uk.xensource.com> <5613C773.5030901@citrix.com> <1444137461.5302.167.camel@citrix.com> <5624C7C3.2030007@suse.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <5624C7C3.2030007@suse.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Juergen Gross , Ian Campbell , Wei Liu Cc: xen-devel@lists.xen.org, ian.jackson@eu.citrix.com, stefano.stabellini@eu.citrix.com List-Id: xen-devel@lists.xenproject.org On 19/10/15 11:36, Juergen Gross wrote: > On 10/06/2015 03:17 PM, Ian Campbell wrote: >> On Tue, 2015-10-06 at 14:06 +0100, Andrew Cooper wrote: >>> On 06/10/15 13:58, Wei Liu wrote: >>>> On Tue, Oct 06, 2015 at 01:52:16PM +0100, Andrew Cooper wrote: >>>>> On 06/10/15 12:35, Juergen Gross wrote: >>>>>> In tools/libxc/xc_dom_compat_linux.c only xc_linux_build() is >>>>>> currently >>>>>> being used by an in-tree component (qemu-xen). All other functions >>>>>> are >>>>>> superfluous wrappers of the domain builder which can be removed. >>>>>> >>>>>> Suggested-by: Ian Campbell >>>>>> Signed-off-by: Juergen Gross >>>>> Sorry, but NACK. They are *not* superfluous. >>>>> >>>>> XenServer uses them; xc_dom_linux_build() is the only way to apply >>>>> XSA-25 size restrictions to PV kernels and initrds. >>>>> >>>> Could you explain a bit more about this? How could this particular >>>> function apply restrictions? >>>> >>>> Unfortunately XSA-25 is not on XSA page so I have no idea what that >>>> is. >>>> >>>> Wei. >>> >>> Older XSAs are listed on the wiki >>> http://wiki.xen.org/wiki/Security_Announcements >>> >>> XSA-25 introduced xc_dom_{kernel,ramdisk}_max_size() to set upper >>> decompression limits on the kernel and initrd. >>> >>> To use them, a struct xc_dom_image *dom is needed, which means the only >>> safe way of constructing PV domains is >>> >>> xc_dom_allocate() >>> xc_dom_kernel_max_size() >>> xc_dom_ramdisk_max_size() >>> xc_dom_linux_build() >>> >>> To have the decompression limits in place before decompression starts. >> >> No it isn't. >> >> xc_dom_linux_build is implemented in terms of the non-compat xc_dom_* >> functions, so it should be possible to do what you want with out >> using the >> compat wrapper. >> >> If there is some obscure reason this isn't the case then we should fix >> that, not carry around the compat options for ever as a workaround >> (fixes >> include but are not limited to promoting xc_dom_linux_build into a non >> -compat helper). > > Any further comments? > > Andrew, are you okay with Ian's statement? Ah - I see that Xen 4.5 moves xc_dom.h from a private header file to a public header file. This postdates the last time I played "how to make xenctrl/xenguest build a domain". I shall see about modifying XenServer to use the gubbins from xc_dom.h ~Andrew