Re: [PATCH] x86/hvm/dom0: fix PVH initrd and metadata placement

[Xenia Ragiadakou <xenia.ragiadakou@xxxxxxx>]

On 26/10/23 14:41, Jan Beulich wrote:

> On 26.10.2023 12:31, Andrew Cooper wrote:
> > On 26/10/2023 9:34 am, Xenia Ragiadakou wrote:
> > > On 26/10/23 10:35, Jan Beulich wrote:
> > > > On 26.10.2023 08:45, Xenia Ragiadakou wrote:
> > > > > Given that start < kernel_end and end > kernel_start, the logic that
> > > > > determines the best placement for dom0 initrd and metadata, does not
> > > > > take into account the two cases below:
> > > > > (1) start > kernel_start && end > kernel_end
> > > > > (2) start < kernel_start && end < kernel_end
> > > > >
> > > > > In case (1), the evaluation will result in end = kernel_start
> > > > > i.e. end < start, and will load initrd in the middle of the kernel.
> > > > > In case (2), the evaluation will result in start = kernel_end
> > > > > i.e. end < start, and will load initrd at kernel_end, that is out
> > > > > of the memory region under evaluation.
> > > > >             
> > > > I agree there is a problem if the kernel range overlaps but is not fully
> > > > contained in the E820 range under inspection. I'd like to ask though
> > > > under what conditions that can happen, as it seems suspicious for the
> > > > kernel range to span multiple E820 ranges.
> > > >           
> > > We tried to boot Zephyr as pvh dom0 and its load address was under 1MB.
> > >
> > > I know ... that maybe shouldn't have been permitted at all, but
> > > nevertheless we hit this issue.
> > >         
> > Zephyr is linked to run at 4k.  That's what the ELF Headers say, and the
> > entrypoint is not position-independent.
> >       
> Very interesting. What size is their kernel? And, Xenia, can you provide
> the E820 map that you were finding the collision with?
>

Sure.

Xen-e820 RAM map:

     [0000000000000000, 000000000009fbff] (usable)
     [000000000009fc00, 000000000009ffff] (reserved)
     [00000000000f0000, 00000000000fffff] (reserved)
     [0000000000100000, 000000007ffdefff] (usable)
     [000000007ffdf000, 000000007fffffff] (reserved)
     [00000000b0000000, 00000000bfffffff] (reserved)
     [00000000fed1c000, 00000000fed1ffff] (reserved)
     [00000000fffc0000, 00000000ffffffff] (reserved)
     [0000000100000000, 000000027fffffff] (usable)
    
    (XEN) ELF: phdr: paddr=0x1000 memsz=0x8000
    (XEN) ELF: phdr: paddr=0x100000 memsz=0x28a90
    (XEN) ELF: phdr: paddr=0x128aa0 memsz=0x7560
    (XEN) ELF: memory: 0x1000 -> 0x130000

> > So trying to put the binary anywhere else is going to work about as well
> > having the notes section misalign the pagetables by 0x20 bytes[1].
> >
> > ~Andrew
> >
> > [1] Guess what was causing the "Zephyr doesn't boot PVH" issues.  Which
> > is doubly irritating because about 6h of debugging prior, I'd pointed
> > out that the linker was complaining about an orphaned section and that
> > that ought to be fixed before trying to debug further...
> >       
>