linux-stable.git/arch/x86/boot, branch linux-5.0.y

x86/build: Specify elf_i386 linker emulation explicitly for i386 objects

2019-04-05T20:34:51+00:00

[ Upstream commit 927185c124d62a9a4d35878d7f6d432a166b74e3 ]

The kernel uses the OUTPUT_FORMAT linker script command in it's linker
scripts. Most of the time, the -m option is passed to the linker with
correct architecture, but sometimes (at least for x86_64) the -m option
contradicts the OUTPUT_FORMAT directive.

Specifically, arch/x86/boot and arch/x86/realmode/rm produce i386 object
files, but are linked with the -m elf_x86_64 linker flag when building
for x86_64.

The GNU linker manpage doesn't explicitly state any tie-breakers between
-m and OUTPUT_FORMAT. But with BFD and Gold linkers, OUTPUT_FORMAT
overrides the emulation value specified with the -m option.

LLVM lld has a different behavior, however. When supplied with
contradicting -m and OUTPUT_FORMAT values it fails with the following
error message:

  ld.lld: error: arch/x86/realmode/rm/header.o is incompatible with elf_x86_64

Therefore, just add the correct -m after the incorrect one (it overrides
it), so the linker invocation looks like this:

  ld -m elf_x86_64 -z max-page-size=0x200000 -m elf_i386 --emit-relocs -T \
    realmode.lds header.o trampoline_64.o stack.o reboot.o -o realmode.elf

This is not a functional change for GNU ld, because (although not
explicitly documented) OUTPUT_FORMAT overrides -m EMULATION.

Tested by building x86_64 kernel with GNU gcc/ld toolchain and booting
it in QEMU.

 [ bp: massage and clarify text. ]

Suggested-by: Dmitry Golovin 
Signed-off-by: George Rimar 
Signed-off-by: Tri Vo 
Signed-off-by: Borislav Petkov 
Tested-by: Tri Vo 
Tested-by: Nick Desaulniers 
Cc: "H. Peter Anvin" 
Cc: Ingo Molnar 
Cc: Michael Matz 
Cc: Thomas Gleixner 
Cc: morbo@google.com
Cc: ndesaulniers@google.com
Cc: ruiu@google.com
Cc: x86-ml 
Link: https://lkml.kernel.org/r/20190111201012.71210-1-trong@android.com
Signed-off-by: Sasha Levin

x86/boot/compressed/64: Do not read legacy ROM on EFI system

2019-03-10T06:09:00+00:00

commit 6f913de3231e1d70a871135b38219da7810df218 upstream.

EFI systems do not necessarily provide a legacy ROM. If the ROM is missing
the memory is not mapped at all.

Trying to dereference values in the legacy ROM area leads to a crash on
Macbook Pro.

Only look for values in the legacy ROM area for non-EFI system.

Fixes: 3548e131ec6a ("x86/boot/compressed/64: Find a place for 32-bit trampoline")
Reported-by: Pitam Mitra 
Signed-off-by: Kirill A. Shutemov 
Signed-off-by: Thomas Gleixner 
Tested-by: Bockjoo Kim 
Cc: bp@alien8.de
Cc: hpa@zytor.com
Cc: stable@vger.kernel.org
Link: https://lkml.kernel.org/r/20190219075224.35058-1-kirill.shutemov@linux.intel.com
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=202351
Signed-off-by: Greg Kroah-Hartman

x86/boot/compressed/64: Do not corrupt EDX on EFER.LME=1 setting

2019-02-06T17:56:18+00:00

RDMSR in the trampoline code overwrites EDX but that register is used
to indicate whether 5-level paging has to be enabled and if clobbered,
leads to failure to boot on a 5-level paging machine.

Preserve EDX on the stack while we are dealing with EFER.

Fixes: b677dfae5aa1 ("x86/boot/compressed/64: Set EFER.LME=1 in 32-bit trampoline before returning to long mode")
Reported-by: Kyle D Pelton 
Signed-off-by: Kirill A. Shutemov 
Signed-off-by: Borislav Petkov 
Cc: dave.hansen@linux.intel.com
Cc: "H. Peter Anvin" 
Cc: Ingo Molnar 
Cc: Thomas Gleixner 
Cc: Wei Huang 
Cc: x86-ml 
Link: https://lkml.kernel.org/r/20190206115253.1907-1-kirill.shutemov@linux.intel.com

x86/boot/compressed/64: Set EFER.LME=1 in 32-bit trampoline before returning to long mode

2019-01-29T20:58:59+00:00

In some old AMD KVM implementation, guest's EFER.LME bit is cleared by KVM
when the hypervsior detects that the guest sets CR0.PG to 0. This causes
the guest OS to reboot when it tries to return from 32-bit trampoline code
because the CPU is in incorrect state: CR4.PAE=1, CR0.PG=1, CS.L=1, but
EFER.LME=0.  As a precaution, set EFER.LME=1 as part of long mode
activation procedure. This extra step won't cause any harm when Linux is
booted on a bare-metal machine.

Signed-off-by: Wei Huang 
Signed-off-by: Thomas Gleixner 
Acked-by: Kirill A. Shutemov 
Cc: bp@alien8.de
Cc: hpa@zytor.com
Link: https://lkml.kernel.org/r/20190104054411.12489-1-wei@redhat.com

kbuild: remove redundant target cleaning on failure

2019-01-06T00:46:51+00:00

Since commit 9c2af1c7377a ("kbuild: add .DELETE_ON_ERROR special
target"), the target file is automatically deleted on failure.

The boilerplate code

  ... || { rm -f $@; false; }

is unneeded.

Signed-off-by: Masahiro Yamada

Merge branch 'x86-boot-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip

2018-12-27T00:56:00+00:00

Pull x86 boot updates from Ingo Molnar:
 "Two cleanups"

* 'x86-boot-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
  x86/boot: Add missing va_end() to die()
  x86/boot: Simplify the detect_memory*() control flow

Merge branch 'efi-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip

2018-12-09T22:03:56+00:00

Pull EFI fixes from Ingo Molnar:
 "Two fixes: a large-system fix and an earlyprintk fix with certain
  resolutions"

* 'efi-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
  x86/earlyprintk/efi: Fix infinite loop on some screen widths
  x86/efi: Allocate e820 buffer before calling efi_exit_boot_service

x86/efi: Allocate e820 buffer before calling efi_exit_boot_service

2018-11-30T07:30:07+00:00

The following commit:

  d64934019f6c ("x86/efi: Use efi_exit_boot_services()")

introduced a regression on systems with large memory maps causing them
to hang on boot. The first "goto get_map" that was removed from
exit_boot() ensured there was enough room for the memory map when
efi_call_early(exit_boot_services) was called. This happens when
(nr_desc > ARRAY_SIZE(params->e820_table).

Chain of events:

  exit_boot()
    efi_exit_boot_services()
      efi_get_memory_map                  <- at this point the mm can't grow over 8 desc
      priv_func()
        exit_boot_func()
          allocate_e820ext()              <- new mm grows over 8 desc from e820 alloc
      efi_call_early(exit_boot_services)  <- mm key doesn't match so retry
      efi_call_early(get_memory_map)      <- not enough room for new mm
      system hangs

This patch allocates the e820 buffer before calling efi_exit_boot_services()
and fixes the regression.

 [ mingo: minor cleanliness edits. ]

Signed-off-by: Eric Snowberg 
Signed-off-by: Ard Biesheuvel 
Cc: 
Cc: Andy Lutomirski 
Cc: Arend van Spriel 
Cc: Bhupesh Sharma 
Cc: Borislav Petkov 
Cc: Dave Hansen 
Cc: Hans de Goede 
Cc: Joe Perches 
Cc: Jon Hunter 
Cc: Julien Thierry 
Cc: Linus Torvalds 
Cc: Marc Zyngier 
Cc: Matt Fleming 
Cc: Nathan Chancellor 
Cc: Peter Zijlstra 
Cc: Sai Praneeth Prakhya 
Cc: Sedat Dilek 
Cc: Thomas Gleixner 
Cc: YiFei Zhu 
Cc: linux-efi@vger.kernel.org
Link: http://lkml.kernel.org/r/20181129171230.18699-2-ard.biesheuvel@linaro.org
Signed-off-by: Ingo Molnar

x86/boot: Add missing va_end() to die()

2018-11-28T19:06:07+00:00

Each call to va_start() must have a corresponding call to va_end()
before the end of the function. Add the missing va_end().

Found with Coccinelle.

Signed-off-by: Mattias Jacobsson <2pi@mok.nu>
Signed-off-by: Borislav Petkov 
Cc: "H. Peter Anvin" 
Cc: Ingo Molnar 
Cc: Thomas Gleixner 
Link: https://lkml.kernel.org/r/20181128161607.10973-1-2pi@mok.nu

x86/boot: Mostly revert commit ae7e1238e68f2a ("Add ACPI RSDP address to setup_header")

2018-11-20T08:43:10+00:00

Peter Anvin pointed out that commit:

  ae7e1238e68f2a ("x86/boot: Add ACPI RSDP address to setup_header")

should be reverted as setup_header should only contain items set by the
legacy BIOS.

So revert said commit. Instead of fully reverting the dependent commit
of:

  e7b66d16fe4172 ("x86/acpi, x86/boot: Take RSDP address for boot params if available")

just remove the setup_header reference in order to replace it by
a boot_params in a followup patch.

Suggested-by: "H. Peter Anvin" 
Signed-off-by: Juergen Gross 
Cc: Linus Torvalds 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Cc: boris.ostrovsky@oracle.com
Cc: bp@alien8.de
Cc: daniel.kiper@oracle.com
Cc: sstabellini@kernel.org
Cc: xen-devel@lists.xenproject.org
Link: http://lkml.kernel.org/r/20181120072529.5489-2-jgross@suse.com
Signed-off-by: Ingo Molnar