[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH] libxc: remove most of tools/libxc/xc_dom_compat_linux.c



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 <ian.campbell@xxxxxxxxxx>
>>> Signed-off-by: Juergen Gross <jgross@xxxxxxxx>
>> 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.

~Andrew

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.