Re: [PATCH] libelf: Handle PVH kernels lacking ENTRY elfnote

[Jason Andryuk <jandryuk@xxxxxxxxx>]

On Wed, Oct 14, 2020 at 12:02 PM Jan Beulich <jbeulich@xxxxxxxx> wrote:
>
> On 14.10.2020 17:31, Jason Andryuk wrote:
> > Linux kernels only have an ENTRY elfnote when built with CONFIG_PV.  A
> > kernel build CONFIG_PVH=y CONFIG_PV=n lacks the note.  In this case,
> > virt_entry will be UNSET_ADDR, overwritten by the ELF header e_entry,
> > and fail the check against the virt address range.

Oh, these should be CONFIG_XEN_PVH=y and CONFIG_XEN_PV=n

> > Change the code to only check virt_entry against the virtual address
> > range if it was set upon entry to the function.
>
> Not checking at all seems wrong to me. The ELF spec anyway says
> "virtual address", so an out of bounds value is at least suspicious.
>
> > Maybe the overwriting of virt_entry could be removed, but I don't know
> > if there would be unintended consequences where (old?) kernels don't
> > have an elfnote, but do have an in-range e_entry?  The failing kernel I
> > just looked at has an e_entry of 0x1000000.
>
> And if you dropped the overwriting, what entry point would we use
> in the absence of an ELF note?

elf_xen_note_check currently has:

    /* PVH only requires one ELF note to be set */
    if ( parms->phys_entry != UNSET_ADDR32 )
    {
        elf_msg(elf, "ELF: Found PVH image\n");
        return 0;
    }

> I'd rather put up the option of adjusting the entry (or the check),
> if it looks like a valid physical address.

The function doesn't know if the image will be booted PV or PVH, so I
guess we do all the checks, but use 'parms->phys_entry != UNSET_ADDR32
&& parms->virt_entry == UNSET_ADDR' to conditionally skip checking
virt?

Regards,
Jason