kernel.git/arch/x86/boot/tools, branch linux-3.11.y

x86/boot: Close opened file descriptor

2013-06-19T11:32:19Z

During build we open a file, read that but do not close it. Fix that by sticking fclose() at the right place. Signed-off-by: Jiri Slaby Link: http://lkml.kernel.org/r/1371628383-11216-1-git-send-email-jslaby@suse.cz Signed-off-by: Ingo Molnar Cc: "H. Peter Anvin" Cc: x86@kernel.org

x86, build: Dynamically find entry points in compressed startup code

2013-01-28T04:19:37Z

We have historically hard-coded entry points in head.S just so it's easy to build the executable/bzImage headers with references to them. Unfortunately, this leads to boot loaders abusing these "known" addresses even when they are *explicitly* told that they "should look at the ELF header to find this address, as it may change in the future". And even when the address in question *has* actually been changed in the past, without fanfare or thought to compatibility. Thus we have bootloaders doing stunningly broken things like jumping to offset 0x200 in the kernel startup code in 64-bit mode, *hoping* that startup_64 is still there (it has moved at least once before). And hoping that it's actually a 64-bit kernel despite the fact that we don't give them any indication of that fact. This patch should hopefully remove the temptation to abuse internal addresses in future, where sternly worded comments have not sufficed. Instead of having hard-coded addresses and saying "please don't abuse these", we actually pull the addresses out of the ELF payload into zoffset.h, and make build.c shove them back into the right places in the bzImage header. Rather than including zoffset.h into build.c and thus having to rebuild the tool for every kernel build, we parse it instead. The parsing code is small and simple. This patch doesn't actually move any of the interesting entry points, so any offending bootloader will still continue to "work" after this patch is applied. For some version of "work" which includes jumping into the compressed payload and crashing, if the bzImage it's given is a 32-bit kernel. No change there then. [ hpa: some of the issues in the description are addressed or retconned by the 2.12 boot protocol. This patch has been edited to only remove fixed addresses that were *not* thus retconned. ] Signed-off-by: David Woodhouse Link: http://lkml.kernel.org/r/1358513837.2397.247.camel@shinybook.infradead.org Signed-off-by: H. Peter Anvin Cc: Matt Fleming

x86, efi stub: Add .reloc section back into image

2012-06-07T16:52:33Z

Some UEFI firmware will not load a .efi with a .reloc section with a size of 0. Therefore, we create a .efi image with 4 main areas and 3 sections. 1. PE/COFF file header 2. .setup section (covers all setup code following the first sector) 3. .reloc section (contains 1 dummy reloc entry, created in build.c) 4. .text section (covers the remaining kernel image) To make room for the new .setup section data, the header bugger_off_msg had to be shortened. Reported-by: Henrik Rydberg Signed-off-by: Jordan Justen Link: http://lkml.kernel.org/r/1339085121-12760-1-git-send-email-jordan.l.justen@intel.com Tested-by: Lee G Rosenbaum Tested-by: Henrik Rydberg Cc: Matt Fleming Signed-off-by: H. Peter Anvin

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

2012-05-23T17:40:34Z

Pull x86 EFI updates from Ingo Molnar: "This patchset makes changes to the bzImage EFI header, so that it can be signed with a secure boot signature tool. It should not affect anyone who is not using the EFI self-boot feature in any way." * 'x86-efi-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: x86, efi: Fix NumberOfRvaAndSizes field in PE32 header for EFI_STUB x86, efi: Fix .text section overlapping image header for EFI_STUB x86, efi: Fix issue of overlapping .reloc section for EFI_STUB

x86, efi: Add dedicated EFI stub entry point

2012-04-16T18:41:44Z

The method used to work out whether we were booted by EFI firmware or via a boot loader is broken. Because efi_main() is always executed when booting from a boot loader we will dereference invalid pointers either on the stack (CONFIG_X86_32) or contained in %rdx (CONFIG_X86_64) when searching for an EFI System Table signature. Instead of dereferencing these invalid system table pointers, add a new entry point that is only used when booting from EFI firmware, when we know the pointer arguments will be valid. With this change legacy boot loaders will no longer execute efi_main(), but will instead skip EFI stub initialisation completely. [ hpa: Marking this for urgent/stable since it is a regression when the option is enabled; without the option the patch has no effect ] Signed-off-by: Matt Fleming Link: http://lkml.kernel.org/r/1334584744.26997.14.camel@mfleming-mobl1.ger.corp.intel.com Reported-by: Jordan Justen Signed-off-by: H. Peter Anvin Cc: v3.3

Merge branch x86/build into x86/efi and fix up arch/x86/boot/tools/build.c

2012-03-28T20:11:36Z

Reason for merge: The updates to the EFI boot stub generation conflicted with the changes to properly use the get/put_unaligned_le*() macros to generate images. This merge commit completes the conversion in arch/x86/boot/tools/build.c including the places in the code which had been changed on the x86/efi branch. Resolved Conflicts: arch/x86/boot/tools/build.c Signed-off-by: H. Peter Anvin

x86, efi: Fix .text section overlapping image header for EFI_STUB

2012-03-26T20:10:01Z

This change modifes the PE .text section to start after the first sector of the kernel image. The header may be modified by the UEFI secure boot signing, so it is not appropriate for it to be included in one of the image sections. Since the sections are part of the secure boot hash, this modification to the .text section contents would invalidate the secure boot signed hash. Note: UEFI secure boot does hash the image header, but fields that are changed by the signing process are excluded from the hash calculation. This exclusion process is only handled for the image header, and not image sections. Luckily, we can still easily boot without the first sector by initializing a few fields in arch/x86/boot/compressed/eboot.c. Signed-off-by: Matt Fleming Link: http://lkml.kernel.org/r/1332520506-6472-3-git-send-email-jordan.l.justen@intel.com [jordan.l.justen@intel.com: set .text vma & file offset] Signed-off-by: Jordan Justen Signed-off-by: H. Peter Anvin

x86, build: Fix portability issues when cross-building

2012-02-29T07:40:56Z

It would appear that we never actually generated a correct CRC when building on a bigendian machine. Depending on the word size, we would either generate an all-zero CRC (64-bit machine) or a byte-swapped CRC (32-bit machine.) Fix the types used so we don't arbitrarily use a 64-bit word to hold 32-bit numbers, and pass the CRC through put_unaligned_le32() like all the other numbers. Signed-off-by: H. Peter Anvin Cc: Stephen Rothwell Cc: Matt Fleming Cc: Andrew Morton Cc: Nick Bowler Link: http://lkml.kernel.org/r/20120229111322.9eb4b23ff1672e8853ad3b3b@canb.auug.org.au

x86, tools: Remove unneeded header files from tools/build.c

2012-02-29T07:40:15Z

We include and , but none of those header files actually provide anything this file needs. Furthermore, it breaks cross-compilation, so just remove them. Reported-by: Stephen Rothwell Reported-by: Ingo Molnar Signed-off-by: H. Peter Anvin Cc: Matt Fleming Cc: Andrew Morton Cc: Nick Bowler Link: http://lkml.kernel.org/r/20120229111322.9eb4b23ff1672e8853ad3b3b@canb.auug.org.au

x86, efi: Fix endian issues and unaligned accesses

2012-02-28T18:23:02Z

We may need to convert the endianness of the data we read from/write to 'buf', so let's use {get,put}_unaligned_le32() to do that. Failure to do so can result in accessing invalid memory, leading to a segfault. Stephen Rothwell noticed this bug while cross-building an x86_64 allmodconfig kernel on PowerPC. We need to read from and write to 'buf' a byte at a time otherwise it's possible we'll perform an unaligned access, which can lead to bus errors when cross-building an x86 kernel on risc architectures. Cc: H. Peter Anvin Cc: Nick Bowler Tested-by: Stephen Rothwell Reported-by: Stephen Rothwell Signed-off-by: Matt Fleming Link: http://lkml.kernel.org/r/1330436245-24875-6-git-send-email-matt@console-pimps.org Signed-off-by: H. Peter Anvin