Re: [Xen-devel] [PATCH v7 01/14] x86: move xen ELF end of image to 16 MiB

[Daniel Kiper <daniel.kiper@xxxxxxxxxx>]

On Mon, Sep 26, 2016 at 04:39:37AM -0600, Jan Beulich wrote:
> >>> On 23.09.16 at 23:47, <daniel.kiper@xxxxxxxxxx> wrote:
> > It seems that from xen ELF image POV _end symbol properly determine
> > image end. However, taking into account that initial Xen image mapping
> > covers 16 MiB it looks that it is not sufficient. Currently bootloader
> > potentially may load xen ELF image at 1 MiB and let's say put Linux
> > kernel or initrd at 8 MiB. Nothing forbids it. This means that initially
> > Xen image mapping may cover not only Xen image but also loaded modules.
>
> Okay, up to here you just describe the state of things, which is fine.
>
> > So, let's move end of xen ELF image to 16 MiB. This way we avoid above
> > mentioned issue because bootloader will be forced to allocate 15 MiB
> > memory region for image. Then it (bootloader) would not be able to put
> > in this place anything else because from its POV simply this memory
> > region will be allocated and used.
>
> But here you state what the patch does, but not what problem you
> solve. And my problem here is that I don't see any problem to be
> solved: There may be an overlap of address ranges, but I don't see
> that memory being used in two different way. In fact the 16Mb
> mapping is just a mapping, without us using anything outside the
> Xen image range afaics.

However, this begs the question: Why do we map 16 MiB in Xen image address
space if we do not expect anything sensible beyond the _end symbol? Should
not we stop just beyond the _end at 2 MiB boundary? This way if something
accesses anything between _end and 16 MiB via Xen image mapping then way of
failure is more predictable than now. IIRC, this region (from _end to 16 MiB)
is not even zeroed, so, unexpected things may happen.

Well, this is not grave error but I think that it is worth discussing.

Daniel

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