[Xen-devel] RE: tboot support broken by c/s 19075

["Cihula, Joseph" <joseph.cihula@xxxxxxxxx>]

> From: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx 
> [mailto:xen-devel-bounces@xxxxxxxxxxxxxxxxxxx] On
> Behalf Of Cihula, Joseph
> Sent: Wednesday, January 28, 2009 2:19 PM
>
> The following changeset breaks Xen support for tboot (the version of tboot in
> SourceForge/bughost as well as with recent patches).  I am trying to see what 
> aspect of this
> is causing the problem, but if perhaps someone could see something obvious 
> and save me some
> time...
>
> The error is:
> (XEN) Early fatal page fault at e008:ffff828c80117c22 (cr2=0000000001157202, 
> ec=
> 0000)
> (XEN) Stack dump: 0000000000021c20 0000000000000378 ffff828c801ee0c1 
> ffff828c801
> ed6c1 ffff828c801ed4e0 0000000001157000 ffff828c80123680 00000000ffffffff 
> 000000
> 0000000000 0000000000000000 0000000000f17e00 0000000000000004 
> 0000000000000004 f
> fff828c801ca6bd 0000000001157202 0000000000000000 ffff828c80117c22 
> 000000000000e
> 008 0000000000010002 ffff828c80257e40 0000000000000000 ffff828c80200245 
> 00000000
> 01157000 ffff828c80200289 ffff830000000000 ffff828c801fdbd7 0000000000000000 
> 000
> 0000000000000 0000000000000000 0000000000000000 0000000000000000 
> 000000000000000
> 0 0000000000000000 0000000000000000 ffff83000002cea0 ffff830000021c20 
> 0000000000
> f17e00 0000000000000000 0000000800000000 000000010000006e 0000000000000003 
> 00000
> 000000002f8 0000000000000000 0000000000000000 0000000000000001 
> 000000007a01f9f0
> 000000007a316018 0000000000000000 0000000000000000 ffff828c801000b5 
> 000000000000
> 0000 0000000000000000 0000000000000000 0000000000000000 0000000000000000 
> 0000000
> 000000000 0000000000000000 0000000000000000 0000000000000000 0000000000000000 
> 00
> 00000000000000 0000000000000000 0000000000000000 0000000000000000 
> 00000000000000
> 00 0000000000000000 0000000000000000 0000000000000000 0000000000000000 
> 000000000
> 0000000 0000000000000000 0000000000000000 0000000000000000 0000000000000000 
> 0000
> 000000000000 0000000000000000 00000000fffff000
>
> Joe
>
> changeset:   19075:9b0289a165eb
> user:        Keir Fraser <keir.fraser@xxxxxxxxxx>
> date:        Thu Jan 22 18:00:48 2009 +0000
> files:       xen/arch/x86/Makefile xen/arch/x86/bzimage.c 
> xen/arch/x86/domain_build.c
> xen/arch/x86/setup.c xen/common/inflate.c xen/include/xen/sched.h
> description:
> x86: Support booting a bzImage format domain 0 kernel.
>
> This requires a bzImage v2.08 or later kernel.
>
> xen/common/inflate.c is taken unmodified from Linux v2.6.28.
>
> Signed-off-by: Ian Campbell <ian.campbell@xxxxxxxxxx>
>
>

I've traced this down to the bzimage_check() fn where it is trying to check if 
the header string is there--the memcmp() is faulting.  But I don't know why yet 
(the module start addr is 0x1157000 and the header is at 0x1157202).

But I think there is a bug in either bzimage_check() or bzimage_headroom().  
bzimage_headroom() calls bzimage_check() as so:
    err = bzimage_check(hdr, image_length);
    if (err < 1)
        return err;
where bzimage_headroom() returns the size of headroom to leave to expand the 
image.
However, one of the code paths in bzimage_check() is:
    if ( hdr->version < VERSION(2,8) ) {
        printk("Cannot load bzImage v%d.%02d at least v2.08 is required\n",
           hdr->version >> 8, hdr->version & 0xff);
        return -EINVAL;
    }
If this path is taken then bzimage_check() will return -22 (EINVAL is 22), 
which bzimage_headroom() will then return, which gets assigned to 
modules_headroom in __start_xen() and modules_headroom is an unsigned 
long--hence it will get a very large value.  I think that all failure paths in 
bzimage_headroom() should return 0?

Joe


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