Skip to content
  1. Jan 20, 2015
  3. Nov 23, 2014
  5. Nov 11, 2014
    • Ard Biesheuvel's avatar
      efi/x86: Move x86 back to libstub · 243b6754
      Ard Biesheuvel authored 
      

This reverts commit 84be8805, which itself reverted my original
attempt to move x86 from #include'ing .c files from across the tree
to using the EFI stub built as a static library.

The issue that affected the original approach was that splitting
the implementation into several .o files resulted in the variable
'efi_early' becoming a global with external linkage, which under
-fPIC implies that references to it must go through the GOT. However,
dealing with this additional GOT entry turned out to be troublesome
on some EFI implementations. (GCC's visibility=hidden attribute is
supposed to lift this requirement, but it turned out not to work on
the 32-bit build.)

Instead, use a pure getter function to get a reference to efi_early.
This approach results in no additional GOT entries being generated,
so there is no need for any changes in the early GOT handling.

Tested-by: default avatarMaarten Lankhorst <maarten.lankhorst@canonical.com>
Signed-off-by: default avatarArd Biesheuvel <ard.biesheuvel@linaro.org>
Signed-off-by: default avatarMatt Fleming <matt.fleming@intel.com>
      243b6754
  7. Nov 04, 2014
  9. Nov 01, 2014
    • Kees Cook's avatar
      x86, boot: Document intermediates more clearly · fb7183ef
      Kees Cook authored 
      

This adds a comment detailing the various intermediate files used to build
the bootable decompression image for the x86 kernel.

Signed-off-by: default avatarKees Cook <keescook@chromium.org>
Reviewed-by: default avatarJosh Triplett <josh@joshtriplett.org>
Cc: Matt Fleming <matt.fleming@intel.com>
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Junjie Mao <eternal.n08@gmail.com>
Link: http://lkml.kernel.org/r/20141031162204.GA26268@www.outflux.net


Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      fb7183ef
    • Junjie Mao's avatar
      x86, kaslr: Prevent .bss from overlaping initrd · e6023367
      Junjie Mao authored 
      

When choosing a random address, the current implementation does not take into
account the reversed space for .bss and .brk sections. Thus the relocated kernel
may overlap other components in memory. Here is an example of the overlap from a
x86_64 kernel in qemu (the ranges of physical addresses are presented):

 Physical Address

    0x0fe00000                  --+--------------------+  <-- randomized base
                               /  |  relocated kernel  |
                   vmlinux.bin    | (from vmlinux.bin) |
    0x1336d000    (an ELF file)   +--------------------+--
                               \  |                    |  \
    0x1376d870                  --+--------------------+   |
                                  |    relocs table    |   |
    0x13c1c2a8                    +--------------------+   .bss and .brk
                                  |                    |   |
    0x13ce6000                    +--------------------+   |
                                  |                    |  /
    0x13f77000                    |       initrd       |--
                                  |                    |
    0x13fef374                    +--------------------+

The initrd image will then be overwritten by the memset during early
initialization:

[    1.655204] Unpacking initramfs...
[    1.662831] Initramfs unpacking failed: junk in compressed archive

This patch prevents the above situation by requiring a larger space when looking
for a random kernel base, so that existing logic can effectively avoids the
overlap.

[kees: switched to perl to avoid hex translation pain in mawk vs gawk]
[kees: calculated overlap without relocs table]

Fixes: 82fa9637 ("x86, kaslr: Select random position from e820 maps")
Reported-by: default avatarFengguang Wu <fengguang.wu@intel.com>
Signed-off-by: default avatarJunjie Mao <eternal.n08@gmail.com>
Signed-off-by: default avatarKees Cook <keescook@chromium.org>
Cc: Josh Triplett <josh@joshtriplett.org>
Cc: Matt Fleming <matt.fleming@intel.com>
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Vivek Goyal <vgoyal@redhat.com>
Cc: Andi Kleen <ak@linux.intel.com>
Cc: stable@vger.kernel.org
Link: http://lkml.kernel.org/r/1414762838-13067-1-git-send-email-eternal.n08@gmail.com


Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      e6023367
  11. Oct 03, 2014
    • Andre Müller's avatar
      x86/efi: Adding efi_printks on memory allocationa and pci.reads · 77e21e87
      Andre Müller authored 
      All other calls to allocate memory seem to make some noise already, with the
exception of two calls (for gop, uga) in the setup_graphics path.

The purpose is to be noisy on worrysome errors immediately.

commit fb86b244 ("x86/efi: Add better error logging to EFI boot
stub") introduces printing false alarms for lots of hardware. Rather
than playing Whack a Mole with non-fatal exit conditions, try the other
way round.

This is per Matt Fleming's suggestion:

> Where I think we could improve things
> is by adding efi_printk() message in certain error paths. Clearly, not
> all error paths need such messages, e.g. the EFI_INVALID_PARAMETER path
> you highlighted above, but it makes sense for memory allocation and PCI
> read failures.

Link: http://article.gmane.org/gmane.linux.kernel.efi/4628


Signed-off-by: default avatarAndre Müller <andre.muller@web.de>
Cc: Ulf Winkelvos <ulf@winkelvos.de>
Signed-off-by: default avatarMatt Fleming <matt.fleming@intel.com>
      77e21e87
    • Matt Fleming's avatar
      efi: Add efi= parameter parsing to the EFI boot stub · 5a17dae4
      Matt Fleming authored 
      

We need a way to customize the behaviour of the EFI boot stub, in
particular, we need a way to disable the "chunking" workaround, used
when reading files from the EFI System Partition.

One of my machines doesn't cope well when reading files in 1MB chunks to
a buffer above the 4GB mark - it appears that the "chunking" bug
workaround triggers another firmware bug. This was only discovered with
commit 4bf7111f ("x86/efi: Support initrd loaded above 4G"), and
that commit is perfectly valid. The symptom I observed was a corrupt
initrd rather than any kind of crash.

efi= is now used to specify EFI parameters in two very different
execution environments, the EFI boot stub and during kernel boot.

There is also a slight performance optimization by enabling efi=nochunk,
but that's offset by the fact that you're more likely to run into
firmware issues, at least on x86. This is the rationale behind leaving
the workaround enabled by default.

Also provide some documentation for EFI_READ_CHUNK_SIZE and why we're
using the current value of 1MB.

Tested-by: default avatarArd Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Roy Franz <roy.franz@linaro.org>
Cc: Maarten Lankhorst <m.b.lankhorst@gmail.com>
Cc: Leif Lindholm <leif.lindholm@linaro.org>
Cc: Borislav Petkov <bp@suse.de>
Signed-off-by: default avatarMatt Fleming <matt.fleming@intel.com>
      5a17dae4
  13. Oct 01, 2014
  15. Sep 24, 2014
    • Matt Fleming's avatar
      x86/efi: Truncate 64-bit values when calling 32-bit OutputString() · 115c6628
      Matt Fleming authored 
      If we're executing the 32-bit efi_char16_printk() code path (i.e.
running on top of 32-bit firmware) we know that efi_early->text_output
will be a 32-bit value, even though ->text_output has type u64.

Unfortunately, we currently pass ->text_output directly to
efi_early->call() so for CONFIG_X86_32 the compiler will push a 64-bit
value onto the stack, causing the other parameters to be misaligned.

The way we handle this in the rest of the EFI boot stub is to pass
pointers as arguments to efi_early->call(), which automatically do the
right thing (pointers are 32-bit on CONFIG_X86_32, and we simply ignore
the upper 32-bits of the argument register if running in 64-bit mode
with 32-bit firmware).

This fixes a corruption bug when printing strings from the 32-bit EFI
boot stub.

Link: https://bugzilla.kernel.org/show_bug.cgi?id=84241


Signed-off-by: default avatarMatt Fleming <matt.fleming@intel.com>
      115c6628
    • Matt Fleming's avatar
      x86/efi: Delete misleading efi_printk() error message · 56394ab8
      Matt Fleming authored 
      A number of people are reporting seeing the "setup_efi_pci() failed!"
error message in what used to be a quiet boot,

  https://bugzilla.kernel.org/show_bug.cgi?id=81891



The message isn't all that helpful because setup_efi_pci() can return a
non-success error code for a variety of reasons, not all of them fatal.

Let's drop the return code from setup_efi_pci*() altogether, since
there's no way to process it in any meaningful way outside of the inner
__setup_efi_pci*() functions.

Reported-by: default avatarDarren Hart <dvhart@linux.intel.com>
Reported-by: default avatarJosh Boyer <jwboyer@fedoraproject.org>
Cc: Ulf Winkelvos <ulf@winkelvos.de>
Cc: Andre Müller <andre.muller@web.de>
Cc: Ingo Molnar <mingo@kernel.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: default avatarMatt Fleming <matt.fleming@intel.com>
      56394ab8
  17. Sep 23, 2014
    • Matt Fleming's avatar
      Revert "efi/x86: efistub: Move shared dependencies to <asm/efi.h>" · 84be8805
      Matt Fleming authored 
      

This reverts commit f23cf8bd ("efi/x86: efistub: Move shared
dependencies to <asm/efi.h>") as well as the x86 parts of commit
f4f75ad5 ("efi: efistub: Convert into static library").

The road leading to these two reverts is long and winding.

The above two commits were merged during the v3.17 merge window and
turned the common EFI boot stub code into a static library. This
necessitated making some symbols global in the x86 boot stub which
introduced new entries into the early boot GOT.

The problem was that we weren't fixing up the newly created GOT entries
before invoking the EFI boot stub, which sometimes resulted in hangs or
resets. This failure was reported by Maarten on his Macbook pro.

The proposed fix was commit 9cb0e394 ("x86/efi: Fixup GOT in all
boot code paths"). However, that caused issues for Linus when booting
his Sony Vaio Pro 11. It was subsequently reverted in commit
f3670394.

So that leaves us back with Maarten's Macbook pro not booting.

At this stage in the release cycle the least risky option is to revert
the x86 EFI boot stub to the pre-merge window code structure where we
explicitly #include efi-stub-helper.c instead of linking with the static
library. The arm64 code remains unaffected.

We can take another swing at the x86 parts for v3.18.

Conflicts:
	arch/x86/include/asm/efi.h

Tested-by: default avatarJosh Boyer <jwboyer@fedoraproject.org>
Tested-by: default avatarMaarten Lankhorst <maarten.lankhorst@canonical.com>
Tested-by: Leif Lindholm <leif.lindholm@linaro.org> [arm64]
Tested-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>,
Cc: Ingo Molnar <mingo@kernel.org>
Signed-off-by: default avatarMatt Fleming <matt.fleming@intel.com>
      84be8805
    • Linus Torvalds's avatar
      Revert "x86/efi: Fixup GOT in all boot code paths" · f3670394
      Linus Torvalds authored 
      

This reverts commit 9cb0e394.

It causes my Sony Vaio Pro 11 to immediately reboot at startup.

Acked-by: default avatarIngo Molnar <mingo@kernel.org>
Cc: Peter Anvin <hpa@zytor.com>
Cc: Maarten Lankhorst <maarten.lankhorst@canonical.com>
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Matt Fleming <matt.fleming@intel.com>
Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      f3670394
  19. Sep 19, 2014
  21. Sep 08, 2014
    • Matt Fleming's avatar
      x86/efi: Fixup GOT in all boot code paths · 9cb0e394
      Matt Fleming authored 
      

Maarten reported that his Macbook pro 8.2 stopped booting after commit
f23cf8bd ("efi/x86: efistub: Move shared dependencies to
<asm/efi.h>"), the main feature of which is changing the visibility of
symbol 'efi_early' from local to global.

By making 'efi_early' global we end up requiring an entry in the Global
Offset Table. Unfortunately, while we do include code to fixup GOT
entries in the early boot code, it's only called after we've executed
the EFI boot stub.

What this amounts to is that references to 'efi_early' in the EFI boot
stub don't point to the correct place.

Since we've got multiple boot entry points we need to be prepared to
fixup the GOT in multiple places, while ensuring that we never do it
more than once, otherwise the GOT entries will still point to the wrong
place.

Reported-by: default avatarMaarten Lankhorst <maarten.lankhorst@canonical.com>
Tested-by: default avatarMaarten Lankhorst <maarten.lankhorst@canonical.com>
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Signed-off-by: default avatarMatt Fleming <matt.fleming@intel.com>
      9cb0e394
    • Yinghai Lu's avatar
      x86/efi: Only load initrd above 4g on second try · 47226ad4
      Yinghai Lu authored 
      

Mantas found that after commit 4bf7111f ("x86/efi: Support initrd
loaded above 4G"), the kernel freezes at the earliest possible moment
when trying to boot via UEFI on Asus laptop.

Revert to old way to load initrd under 4G on first try, second try will
use above 4G buffer when initrd is too big and does not fit under 4G.

[ The cause of the freeze appears to be a firmware bug when reading
  file data into buffers above 4GB, though the exact reason is unknown.
  Mantas reports that the hang can be avoid if the file size is a
  multiple of 512 bytes, but I've seen some ASUS firmware simply
  corrupting the file data rather than freezing.

  Laszlo fixed an issue in the upstream EDK2 DiskIO code in Aug 2013
  which may possibly be related, commit 4e39b75e ("MdeModulePkg/DiskIoDxe:
  fix source/destination pointer of overrun transfer").

  Whatever the cause, it's unlikely that a fix will be forthcoming
  from the vendor, hence the workaround - Matt ]

Cc: Laszlo Ersek <lersek@redhat.com>
Reported-by: default avatarMantas Mikulėnas <grawity@gmail.com>
Reported-by: default avatarHarald Hoyer <harald@redhat.com>
Tested-by: default avatarAnders Darander <anders@chargestorm.se>
Tested-by: default avatarCalvin Walton <calvin.walton@kepstin.ca>
Signed-off-by: default avatarYinghai Lu <yinghai@kernel.org>
Signed-off-by: default avatarMatt Fleming <matt.fleming@intel.com>
      47226ad4
  23. Aug 17, 2014
  25. Jul 18, 2014
  27. Jul 07, 2014
    • Ard Biesheuvel's avatar
      efi: efistub: Refactor stub components · bd669475
      Ard Biesheuvel authored 
      

In order to move from the #include "../../../xxxxx.c" anti-pattern used
by both the x86 and arm64 versions of the stub to a static library
linked into either the kernel proper (arm64) or a separate boot
executable (x86), there is some prepatory work required.

This patch does the following:
- move forward declarations of functions shared between the arch
  specific and the generic parts of the stub to include/linux/efi.h
- move forward declarations of functions shared between various .c files
  of the generic stub code to a new local header file called "efistub.h"
- add #includes to all .c files which were formerly relying on the
  #includor to include the correct header files
- remove all static modifiers from functions which will need to be
  externally visible once we move to a static library

Signed-off-by: default avatarArd Biesheuvel <ard.biesheuvel@linaro.org>
Signed-off-by: default avatarMatt Fleming <matt.fleming@intel.com>
      bd669475
    • Ard Biesheuvel's avatar
      efi/x86: efistub: Move shared dependencies to <asm/efi.h> · f23cf8bd
      Ard Biesheuvel authored 
      

This moves definitions depended upon both by code under arch/x86/boot
and under drivers/firmware/efi to <asm/efi.h>. This is in preparation of
turning the stub code under drivers/firmware/efi into a static library.

Signed-off-by: default avatarArd Biesheuvel <ard.biesheuvel@linaro.org>
Signed-off-by: default avatarMatt Fleming <matt.fleming@intel.com>
      f23cf8bd
  29. Jun 19, 2014
  31. Jun 16, 2014
  33. May 08, 2014
  35. May 05, 2014
  37. Apr 17, 2014
  39. Apr 10, 2014
  41. Mar 26, 2014
  43. Mar 19, 2014
  45. Mar 05, 2014
    • Matt Fleming's avatar
      x86/boot: Fix non-EFI build · 3db4cafd
      Matt Fleming authored 
      

The kbuild test robot reported the following errors, introduced with
commit 54b52d87 ("x86/efi: Build our own EFI services pointer
table"),

 arch/x86/boot/compressed/head_32.o: In function `efi32_config':
>> (.data+0x58): undefined reference to `efi_call_phys'

 arch/x86/boot/compressed/head_64.o: In function `efi64_config':
>> (.data+0x90): undefined reference to `efi_call6'

Wrap the efi*_config structures in #ifdef CONFIG_EFI_STUB so that we
don't make references to EFI functions if they're not compiled in.

Signed-off-by: default avatarMatt Fleming <matt.fleming@intel.com>
      3db4cafd
  47. Mar 04, 2014
    • Matt Fleming's avatar
      x86/boot: Don't overwrite cr4 when enabling PAE · 108d3f44
      Matt Fleming authored 
      

Some EFI firmware makes use of the FPU during boottime services and
clearing X86_CR4_OSFXSR by overwriting %cr4 causes the firmware to
crash.

Add the PAE bit explicitly instead of trashing the existing contents,
leaving the rest of the bits as the firmware set them.

Cc: H. Peter Anvin <hpa@zytor.com>
Signed-off-by: default avatarMatt Fleming <matt.fleming@intel.com>
      108d3f44
    • Matt Fleming's avatar
      x86/efi: Firmware agnostic handover entry points · b8ff87a6
      Matt Fleming authored 
      

The EFI handover code only works if the "bitness" of the firmware and
the kernel match, i.e. 64-bit firmware and 64-bit kernel - it is not
possible to mix the two. This goes against the tradition that a 32-bit
kernel can be loaded on a 64-bit BIOS platform without having to do
anything special in the boot loader. Linux distributions, for one thing,
regularly run only 32-bit kernels on their live media.

Despite having only one 'handover_offset' field in the kernel header,
EFI boot loaders use two separate entry points to enter the kernel based
on the architecture the boot loader was compiled for,

    (1) 32-bit loader: handover_offset
    (2) 64-bit loader: handover_offset + 512

Since we already have two entry points, we can leverage them to infer
the bitness of the firmware we're running on, without requiring any boot
loader modifications, by making (1) and (2) valid entry points for both
CONFIG_X86_32 and CONFIG_X86_64 kernels.

To be clear, a 32-bit boot loader will always use (1) and a 64-bit boot
loader will always use (2). It's just that, if a single kernel image
supports (1) and (2) that image can be used with both 32-bit and 64-bit
boot loaders, and hence both 32-bit and 64-bit EFI.

(1) and (2) must be 512 bytes apart at all times, but that is already
part of the boot ABI and we could never change that delta without
breaking existing boot loaders anyhow.

Signed-off-by: default avatarMatt Fleming <matt.fleming@intel.com>
      b8ff87a6