--- Comment #32 from ---
A commit references this bug:

Author: dexuan
Date: Thu Mar 30 12:41:21 UTC 2017
New revision: 316272

  MFC: 314547, 314770, 314828, 314891, 314956, 314962, 315235

      loader.efi: reduce the size of the staging area if necessary

      The loader assumes physical memory in [2MB, 2MB + EFI_STAGING_SIZE)
      is Conventional Memory, but actually it may not, e.g. in the case
      of Hyper-V Generation-2 VM (i.e. UEFI VM) running on Windows
      Server 2012 R2 host, there is a BootServiceData memory block at
      the address 47.449MB and the memory is not writable.

      Without the patch, the loader will crash in efi_copy_finish():
      see PR 211746.

      The patch verifies the end of the staging area, and reduces its
      size if necessary. This way, the loader will not try to write into
      the BootServiceData memory any longer.

      Thank Marcel Moolenaar for helping me on this issue!

      The patch also allocates the staging area in the first 1GB memory.
      See the comment in the patch for this.

      PR:               211746
      Reviewed by:      marcel, kib, sephe
      Approved by:      sephe (mentor)
      Sponsored by:     Microsoft
      Differential Revision:

      loader.efi: fix recent UEFI-boot regression on physical machines

      This patch fixes my recent patch
      "loader.efi: reduce the size of the staging area if necessary", which
      causes EFI-boot failure on physical machines since Mar 2:
      on the host there is a 1MB LoaderData memory range, which splits
      the big Conventional Memory range into a small one (15MB) and a
      big one: the small one is too small to hold the staging area.

      We can actually use the LoaderData range safely, because when
      amd64_tramp -> efi_copy_finish() starts to run, we're almost at
      the very end of the efi loader code and we're going to "return"
      to the kernel entry, so we're pretty sure we won't access any loader
      data any more.

      For people who are interested in the details: please see

      PS, some people also reported the regression happened to FreeBSD VM
      running on Bhyve in EFI mode. This patch should resolve it too,
      though I don't have such a setup to test.

      Reviewed by:      sephe
      Approved by:      sephe (mentor)
      Sponsored by:     Microsoft
      Differential Revision:

      loader.efi: fix an off-by-one bug in efi_verify_staging_size()

      Also remove the warning message: it may not be unusual to see
      the memory range containing 2MB is not of EfiConventionalMemory.

      Sponsored by:     Microsoft

      loader.efi: finally fix the off-by-one bug in efi_verify_staging_size()

      r314828(loader.efi: fix an off-by-one bug in efi_verify_staging_size())
      doesn't really fix the bug and this patch adds the missing part.

      It's a shame that I didn't make everything correct at the very

      Sponsored by:     Microsoft

      loader.efi: only reduce the size of the staging area on Hyper-V

      Doing this on physical hosts turns out to be problematic, e.g. see
      24 and 28 in

      To fix the real underlying issue correctly & thoroughly, IMO we need
      a relocatable kernel, but that would require a lot of complicated long
      term work:

      For now, let's only apply efi_verify_staging_size() to VMs running on
      Hyper-V, and restore the old behavior on physical machines since that
      has been working for people for a long period of time, though that's
      potentially unsafe...

      Sponsored by:     Microsoft

      loader.efi: only include the machine/ header files on x86

      The 2 files may not exist on other archs like aarch64 and hence we
      can have a build failure there.

      Reported by:      lwhsu
      Sponsored by:     Microsoft

      loader.efi: use stricter check for Hyper-V

      Some other hypervisors like Xen can pretend to be Hyper-V but obviously
      they can't implement all Hyper-V features. Let's make sure we're genuine
      Hyper-V here.

      Also fix some minor coding style issues.

      PR:               211746
      Sponsored by:     Microsoft

  PR:           211746

_U  stable/11/

You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________ mailing list
To unsubscribe, send any mail to 

Reply via email to