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

[Xen-devel] [PATCH][RESEND][Builder] Check if v_end wraps around to 0



This patch adds a check to see if v_end in setup_guest() wraps around to
0 and lets the builder exit gracefully when it does.

Signed-off-by: Aravindh Puthiyaparambil
<aravindh.puthiyaparambil@xxxxxxxxxx>

> -----Original Message-----
> From: Keir Fraser [mailto:Keir.Fraser@xxxxxxxxxxxx]
> Sent: Thursday, June 01, 2006 6:14 AM
> To: Puthiyaparambil, Aravindh
> Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
> Subject: Re: Malformed image causing builder to crash
> 
> 
> On 31 May 2006, at 18:53, Puthiyaparambil, Aravindh wrote:
> 
> > An image with VIRT_START and ELF_PADDR_OFFSET equal to 0 and its
linker
> > entry at 0xffffffff80000000 (Is this is an malformed image?) causes
the
> > builder to crash in loadelfimage() [line 235] because parray is
going
> > out of bounds. Output from the builder is show below. What seems to
be
> > happening is that in setup_guest(), the variable v_end is becoming
zero
> > after the "for ( nr_pt_pages = 2; ; nr_pt_pages++ )" loop. Also note
> > that the value of nr_pt_pages is very large. The reason is that
> > dsi->v_start is 0 which throws things off. But this is totally valid
so
> > I am not sure what checks need to be introduced to stop this from
> > happening. Should the bounds check for the array be reintroduced?
> 
> The problem is almost certainly a wrap in
> xc_linux_build.c:setup_guest(). v_end is taken from parseelfimage()
and
> then incremented to make room for initrd, page tables, etc. If that
> wraps round to zero then the size check will pass and things will
> generally be screwed.
> 
> We probably need to take care whenever we increment v_end to ensure
> that 'inc < -v_end'.
> 
>   -- Keir

Attachment: libxc_vend.patch
Description: libxc_vend.patch

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel

 


Rackspace

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