Re: [Xen-devel] Xen boot failure with WXN bit set

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

(For clarity this is xen on arm, so x86 folks can stop reading now)

On Thu, 2014-03-27 at 16:41 +0530, Vijay Kilari wrote:
> CC: Xen-dev

Thanks.

> >> I think, by adding more code, there is overflow in code which is going
> >> beyond mapping
> >> area and hence setting WXN bit is causing some piece of code to kept
> >> in writable region
> >> which is set to XN.

How much code/data are you adding?

> >> Looks like there is limit in number of page entries allocated to xen
> >> code & ro data region

The main limit is that Xen must fit in a 2MB super page, although we do
then break that down into 4K mappings so we can apply the XN bit to the
various ptes.

Does the issue occur at the very moment the WXN bit is set or at some
later point? Do you have a log of the trap when it occurs?

> >> My xen size is 591280 bytes.

I think that is small enough to avoid any 2MB issues.

The code which sets the XN bit is:
    /* Break up the Xen mapping into 4k pages and protect them separately. */
    for ( i = 0; i < LPAE_ENTRIES; i++ )
    {
        unsigned long mfn = paddr_to_pfn(xen_paddr) + i;
        unsigned long va = XEN_VIRT_START + (i << PAGE_SHIFT);
        if ( !is_kernel(va) )
            break;
        pte = mfn_to_xen_entry(mfn, WRITEALLOC);
        pte.pt.table = 1; /* 4k mappings always have this bit set */
        if ( is_kernel_text(va) || is_kernel_inittext(va) )
        {
            pte.pt.xn = 0;
            pte.pt.ro = 1;
        }
        if ( is_kernel_rodata(va) )
            pte.pt.ro = 1;
        write_pte(xen_xenmap + i, pte);
        /* No flush required here as page table is not hooked in yet. */
    }

So to have the issue is_kernel_text or is_kernel_inittext would need to
return false for a region which was actually test of some sort.

Or Xen would have to overflow the 2MB region (encoded in the use of
LPAE_ENTRIES above). But I would expect that would cause other sorts of
issues before WXN caused a trap, like a lack of a mapping altogether.

I don't think we need to worry about data and text segments sharing the
same 4K page because the linker script (xen/arch/arm/xen.lds.S)
explicitly aligns the relevant sections to page boundaries. (you can
probably double check that with objdump or readelf somehow).

Ian.


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