[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH v6 01/15] x86: properly calculate ELF end of image address
On Mon, Sep 19, 2016 at 08:52:02AM -0600, Jan Beulich wrote: > >>> On 19.09.16 at 15:56, <daniel.kiper@xxxxxxxxxx> wrote: > > On Mon, Sep 19, 2016 at 05:14:07AM -0600, Jan Beulich wrote: [...] > >> So before taking this patch I'd really like to see proof that what gets > >> done currently does actually go wrong in at least one case. So far I > > > > During initial work on this patch series I discovered that p_memsz in xen > > ELF file is set to unreasonably huge value, IIRC, ~1 GiB. That is why at > > first I enforced 16 MiB here (just temporary workaround) and later proposed > > this patch. Sadly, right now I am not able to find commit which introduced > > this issue. However, it seems that it was "fixed" later by another commit. > > > > Anyway, I am not sure why are you against, IMO, more reliable solution. > > This way we would avoid in the future similar issues which I described > > above. > > I'm not against anything if it gets properly explained. Here, > however, you present some vague statements which even you > can't verify right now as it looks. OK, I did some more tests and found out that after patch "efi: build xen.gz with EFI code" we have following xen ELF file: Program Headers: Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align LOAD 0x000080 0x00100000 0x00100000 0x20c120 0x3ff00000 RWE 0x40 ^^^^^^^^^^ because "nm -nr xen/xen-syms" emits: ffff82d0c0000000 A ALT_START ffff82d08034d000 A __2M_rwdata_end ffff82d08034cc00 A _end ffff82d08034cc00 B __per_cpu_data_end ffff82d08034cc00 B __bss_end [...] ALT_START lives in xen/arch/x86/efi/relocs-dummy.S. relocs-dummy.S provides __base_relocs_start and __base_relocs_end symbols which are referenced in xen/arch/x86/efi/efi-boot.h:efi_arch_relocate_image(). Of course one can argue that maybe we should do some changes in efi_arch_relocate_image() and/or xen/arch/x86/efi/relocs-dummy.S. This is true. However, this is separate issue and we should consider it as such. "efi: build xen.gz with EFI code" patch clearly shows that current method used to calculate <final-exec-addr> mkelf32 argument is based on bogus assumptions and very fragile. So, IMO, it should be changed to something which is more reliable. And my proposal looks quite good. Daniel _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx https://lists.xen.org/xen-devel
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |