[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH 4/8] x86/EFI: redo .reloc section bounds determination


  • To: Jan Beulich <jbeulich@xxxxxxxx>
  • From: Roger Pau Monné <roger.pau@xxxxxxxxxx>
  • Date: Wed, 21 Apr 2021 16:54:50 +0200
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=citrix.com; dmarc=pass action=none header.from=citrix.com; dkim=pass header.d=citrix.com; arc=none
  • Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=IG9p7eBBdYHGuNy1Kf6MRr5odbmVq1Fs2UrrHinblHQ=; b=OgfRJUqnUj2OE27FB3K/ZfROBxzBtx8xnB7fGVnYg4rTKb+cjg0s+GRsr9LstsVT1UYVpiYeJ3IvdW0A8PdQFNkA5AeZtNn/r9blaCQu4uJhzyWrguKMXKy5S13h3U/gpLxNqKJCX+6XWhMsMRXGnft7pB1EiUAIRSRl+MNUvkzj2CalWMrN2cjI52HU+7IgvaEKPWC6VhxzlfCriRlLlBKz4VAc9YBgekUkuYlEPcFAURyWsPDElxO8y00y6sV5tcBhDGQlpWXAhCfhCWg3Ud9E9zgpkeqzLCzycHo8qaQ8mkEGXRaPpXWzr4RmiExRCue98VxLBKqcynMsVPQrPA==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=I9LbDr3xrTno+3qwT6gq0CXU/6KHNK5xItB2lzVXwdvCnxAa6f7aMAw1LxSTrcabiTI9QxPaXUHKa7fRYtragcdzKk8bcl4xrhicdnVQMqZo/T+r+rtYXCuvpYDsXIOOpI/qGtbOn08c4AWw/Gbg3qb9rijf6wIFoK0Fe1HF9SMu8QGMntgqMqQbUguztpCwXF8/X7JZ2/JizgmeEmAl1zWbMopItqBCTZCEDYzq5pFYFDU5xZEz2FArmghI1X6T7EAq8c7sxOnP2afGx50pGKS0oCmwavu+ka/g2AfO0zAJOdRFte4N4gXfWpgR6W79l6KZHjpFrGxFN2GujxBUuQ==
  • Authentication-results: esa1.hc3370-68.iphmx.com; dkim=pass (signature verified) header.i=@citrix.onmicrosoft.com
  • Cc: "xen-devel@xxxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxxx>, Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, Wei Liu <wl@xxxxxxx>
  • Delivery-date: Wed, 21 Apr 2021 14:55:03 +0000
  • Ironport-hdrordr: A9a23:KxmjDqwaPW9wqxOttfu6KrPx9uskLtp033Aq2lEZdDV8btGYm8 eynP4SyB/zj3IrVGs9nM2bUZPsfVr385lp7Y4NeYqzRQWOghrMEKhOz6vHhwfhFSr36/JH2c 5bGZRWJdXsATFB4vrSzxK/F78bruWv1ICNqaPgw2x2TQdsApsQjTtRLgqACEV5SE1nKPMCdK a03cZMqzq+dXl/VK3SakUtZOTfu8bN0KvvfB9uPXUawTOThjCl4qOSKWn64j4iVVp0oIsKwC z+vCHSoo6itPy6zRG07R6o071m3OHP5/EGKMiFis0+IijhhACydO1aKsC/lQFwms6DwhIHl8 TNvgcBMq1Img/sV1DwmzTB8U3B1ysj8HDrw1PwuwqdneXJAAgUJuAEoKAxSGq812MQ+OtS/Y gO4kei871QNh/ElDSV3amxazha0nCajFBnrfQelBVkIOwjQY4Ul6Mz1mVPHqwNGSrrgbpXa9 VGPYXn6PFafUjyVQG+gkBfhNilXnEEFhybWEQ1usuMzzhMnHxipnFovfAiog==
  • Ironport-sdr: AeydEXoJBAGZh21zVyxU3Rv0moHr7IFHkbJkG4YTwCWClrGQ3STc0qszw9P8Cqx3D2lq/FZfl0 9aeIzTyBkjokFbMS7maBKBgXL4cM52ptUAmBWYISKM2fFNJ46B2rizCG1okUXBjpwYQt0KNeBR s6k9IPwfAlT/3sb6C67swbUmYVadzOmcJOvqTzixxe7kVPx3g4dHcfGGJNAQihtl9Zh78a2uWK DBQT/unmIN0TNJGqWG3/DNmsc80RhgeBfJlJpf5B3dhXsm26m++dSrrg0YLYqvG30FWPzimiHY iTg=
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On Wed, Apr 21, 2021 at 12:44:13PM +0200, Jan Beulich wrote:
> On 21.04.2021 11:46, Roger Pau Monné wrote:
> > On Thu, Apr 01, 2021 at 11:45:38AM +0200, Jan Beulich wrote:
> >> There's no need to link relocs-dummy.o into the ELF binary. The two
> >> symbols needed can as well be provided by the linker script. Then our
> >> mkreloc tool also doesn't need to put them in the generated assembler
> >> source.
> > 
> > Maybe I'm just dense today, but I think the message needs to be
> > expanded a bit to mention that while the __base_relocs_{start,end} are
> > not used when loaded as an EFI application, they are used by the EFI
> > code in Xen when booted using the multiboot2 protocol for example, as
> > they are used by efi_arch_relocate_image.
> > 
> > I think relocation is not needed when natively loaded as an EFI
> > application, as then the load address matches the one expected by
> > Xen?
> 
> It's quite the other way around: The EFI loader applies relocations
> to put the binary at its loaded _physical_ address (the image gets
> linked for the final virtual address). Hence we need to apply the
> same relocations a 2nd time (undoing what the EFI loader did)
> before we can branch from the physical (identity mapped) address
> range where xen.efi was loaded to the intended virtual address
> range where we mean to run Xen from.
> 
> For the ELF binary the symbols are needed solely to make ld happy.
> 
> > I also wonder, at some point there where plans for providing a single
> > binary that would work as multiboot{1,2} and also be capable of being
> > loaded as an EFI application (ie: have a PE/COFF header also I assume
> > together with the ELF one), won't the changes here make it more
> > difficult to reach that goal or require reverting later on, as I feel
> > they are adding more differences between the PE binary and the ELF
> > one.
> 
> There were such plans, yes, but from the last round of that series
> I seem to recall that there was at least one issue breaking this
> idea. So no, at this point I'm not intending to take precautions to
> make that work easier (or not further complicate it). This said, I
> don't think the change here complicates anything there.
> 
> > The code LGTM, but I think at least I would like the commit message to
> > be expanded.
> 
> Well, once I know what exactly you're missing there, I can certainly
> try to expand it.

OK, I think I now have a clearer view, the commit message is likely
fine as it already mentions the ELF binary only needs the dummy
__base_relocs_{start,end}, hence it's the EFI binary the one that
requires the relocation symbols.

Acked-by: Roger Pau Monné <roger.pau@xxxxxxxxxx>

Thanks, Roger.



 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.