]> CyberLeo.Net >> Repos - FreeBSD/stable/10.git/commit
MFC: 314547, 314770, 314828, 314891, 314956, 314962, 315235
authordexuan <dexuan@ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f>
Thu, 30 Mar 2017 12:51:44 +0000 (12:51 +0000)
committerdexuan <dexuan@ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f>
Thu, 30 Mar 2017 12:51:44 +0000 (12:51 +0000)
commit5c7bc65d9a101e7fbadb2c4f721722deb6f87ae0
tree86080ead88db177871fd82efc3ff64bbbb3aaa2d
parentdf5d3646902fd384b27d11dabbe23499b0d7ccc1
MFC: 314547, 314770, 314828, 314891, 314956, 314962, 315235

r314547
    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.

    Reviewed by: marcel, kib, sephe
    Approved by: sephe (mentor)
    Sponsored by: Microsoft
    Differential Revision: https://reviews.freebsd.org/D9686

r314770
    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
    https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=211746#c22

    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: https://reviews.freebsd.org/D9904

r314828
    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

r314891
    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 beginning...

    Sponsored by: Microsoft

r314956
    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 comment
    24 and 28 in https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=211746.

    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:  https://reviews.freebsd.org/D9686?id=25414#inline-56969

    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

r314962
    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

r315235
    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.

    Sponsored by: Microsoft

PR: 211746

git-svn-id: svn://svn.freebsd.org/base/stable/10@316273 ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f
sys/boot/efi/loader/copy.c