Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 19 Jun 2021 20:55:08 +0000
From:      bugzilla-noreply@freebsd.org
To:        bugs@FreeBSD.org
Subject:   [Bug 256722] [PATCH] EFI boot: Fix boot freeze on some systems
Message-ID:  <bug-256722-227@https.bugs.freebsd.org/bugzilla/>

next in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D256722

            Bug ID: 256722
           Summary: [PATCH] EFI boot: Fix boot freeze on some systems
           Product: Base System
           Version: CURRENT
          Hardware: amd64
                OS: Any
            Status: New
          Severity: Affects Many People
          Priority: ---
         Component: misc
          Assignee: bugs@FreeBSD.org
          Reporter: dasebek@gmail.com

Created attachment 225941
  --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=3D225941&action=
=3Dedit
[PATCH] efi: loader: Fix a boot freeze on some amd64 systems

This is a copy of a patch from Bug 209821. I am creating a new ticket for i=
t so
that it does not get lost. Users keep reporting that when booting in UEFI m=
ode,
the boot process freezes after displaying framebuffer information. This pat=
ch
fixes the problem for me and for some other people who tried it. After this
patch gets mainlined, it will be easier to distinguish boot issues caused by
this bug from those caused by something else.

This patch fixes a bug that seems to be present on all supported FreeBSD
versions.

This patch addresses a problem that, immediately before the kernel is start=
ed,
the amd64_tramp function calls the efi_copy_finish function to copy the ker=
nel
image from a temporary staging area in the memory to the actual memory addr=
ess
where the kernel expects to be run from. The problem is that the boot loade=
r,
including the efi_copy_finish function, may have been loaded by the UEFI
firmware somewhere in the range where the kernel is being copied to. The
efi_copy_finish function may thus overwrite its own instructions by the ker=
nel
image, causing the system to freeze. This is not a problem for the amd64_tr=
amp
trampoline itself, which is first copied to a safe memory location before i=
t is
executed.

My patch does the following:
- Instead of calling the efi_copy_finish function, which may be located
anywhere in the memory, the copy operation is done by the trampoline itself.
This is the most important part of the patch.
- Adds missing return value checks.
- Before the kernel is copied from the staging area, a new
efi_verify_destination_type function checks that the target memory area is =
safe
to use. If not, it only prints a warning message. (This is useful mainly for
debugging purposes when a system freezes.)

Because I changed the parameters of the trampoline function, I created a new
amd64_tramp_inline function and kept the original amd64_tramp intact in ord=
er
not to break any other existing code. However, the amd64_tramp function does
not seem to be used anywhere else in the existing code, so it could be modi=
fied
directly. The efi_copy_finish function is not needed anymore too.

--=20
You are receiving this mail because:
You are the assignee for the bug.=



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-256722-227>