linux-stable.git/arch/x86/boot, branch v3.3

x86/boot-image: Don't leak phdrs in arch/x86/boot/compressed/misc.c::Parse_elf()

2012-01-26T10:30:29+00:00

We allocate memory with malloc(), but neglect to free it before
the variable 'phdrs' goes out of scope --> leak.

Signed-off-by: Jesper Juhl 
Link: http://lkml.kernel.org/r/alpine.LNX.2.00.1201232332590.8772@swampdragon.chaosbits.net
[ Mostly harmless. ]
Signed-off-by: Ingo Molnar

x86, efi: Break up large initrd reads

2011-12-16T16:34:35+00:00

The efi boot stub tries to read the entire initrd in 1 go, however
some efi implementations hang if too much if asked to read too much
data at the same time. After some experimentation I found out that my
asrock p67 board will hang if asked to read chunks of 4MiB, so use a
safe value.

elilo reads in chunks of 16KiB, but since that requires many read
calls I use a value of 1 MiB.  hpa suggested adding individual
blacklists for when systems are found where this value causes a crash.

Signed-off-by: Maarten Lankhorst 
Link: http://lkml.kernel.org/r/4EEB3A02.3090201@gmail.com
Signed-off-by: H. Peter Anvin

x86, efi: EFI boot stub support

2011-12-12T22:26:10+00:00

There is currently a large divide between kernel development and the
development of EFI boot loaders. The idea behind this patch is to give
the kernel developers full control over the EFI boot process. As
H. Peter Anvin put it,

"The 'kernel carries its own stub' approach been very successful in
dealing with BIOS, and would make a lot of sense to me for EFI as
well."

This patch introduces an EFI boot stub that allows an x86 bzImage to
be loaded and executed by EFI firmware. The bzImage appears to the
firmware as an EFI application. Luckily there are enough free bits
within the bzImage header so that it can masquerade as an EFI
application, thereby coercing the EFI firmware into loading it and
jumping to its entry point. The beauty of this masquerading approach
is that both BIOS and EFI boot loaders can still load and run the same
bzImage, thereby allowing a single kernel image to work in any boot
environment.

The EFI boot stub supports multiple initrds, but they must exist on
the same partition as the bzImage. Command-line arguments for the
kernel can be appended after the bzImage name when run from the EFI
shell, e.g.

Shell> bzImage console=ttyS0 root=/dev/sdb initrd=initrd.img

v7:
 - Fix checkpatch warnings.

v6:

 - Try to allocate initrd memory just below hdr->inird_addr_max.

v5:

 - load_options_size is UTF-16, which needs dividing by 2 to convert
   to the corresponding ASCII size.

v4:

 - Don't read more than image->load_options_size

v3:

 - Fix following warnings when compiling CONFIG_EFI_STUB=n

   arch/x86/boot/tools/build.c: In function ‘main’:
   arch/x86/boot/tools/build.c:138:24: warning: unused variable ‘pe_header’
   arch/x86/boot/tools/build.c:138:15: warning: unused variable ‘file_sz’

 - As reported by Matthew Garrett, some Apple machines have GOPs that
   don't have hardware attached. We need to weed these out by
   searching for ones that handle the PCIIO protocol.

 - Don't allocate memory if no initrds are on cmdline
 - Don't trust image->load_options_size

Maarten Lankhorst noted:
 - Don't strip first argument when booted from efibootmgr
 - Don't allocate too much memory for cmdline
 - Don't update cmdline_size, the kernel considers it read-only
 - Don't accept '\n' for initrd names

v2:

 - File alignment was too large, was 8192 should be 512. Reported by
   Maarten Lankhorst on LKML.
 - Added UGA support for graphics
 - Use VIDEO_TYPE_EFI instead of hard-coded number.
 - Move linelength assignment until after we've assigned depth
 - Dynamically fill out AddressOfEntryPoint in tools/build.c
 - Don't use magic number for GDT/TSS stuff. Requested by Andi Kleen
 - The bzImage may need to be relocated as it may have been loaded at
   a high address address by the firmware. This was required to get my
   macbook booting because the firmware loaded it at 0x7cxxxxxx, which
   triggers this error in decompress_kernel(),

	if (heap > ((-__PAGE_OFFSET-(128<<20)-1) & 0x7fffffff))
		error("Destination address too large");

Cc: Mike Waychison 
Cc: Matthew Garrett 
Tested-by: Henrik Rydberg 
Signed-off-by: Matt Fleming 
Link: http://lkml.kernel.org/r/1321383097.2657.9.camel@mfleming-mobl1.ger.corp.intel.com
Signed-off-by: H. Peter Anvin

doc: fix broken references

2011-09-27T16:08:04+00:00

There are numerous broken references to Documentation files (in other
Documentation files, in comments, etc.). These broken references are
caused by typo's in the references, and by renames or removals of the
Documentation files. Some broken references are simply odd.

Fix these broken references, sometimes by dropping the irrelevant text
they were part of.

Signed-off-by: Paul Bolle 
Signed-off-by: Jiri Kosina

x86, build: Do not set the root_dev field in bzImage

2011-05-25T19:46:05+00:00

This has been obsoleted by the root= commandline and the rdev utility
for many, many years.  People who still depend on this will surely
have a copy of the rdev utility around, the rest of the world gets rid
of another piece of buildhost-dependent data in the build. Thanks to
Paul Bolle for the build.c cleanup.

Cc: Paul Bolle 
Signed-off-by: Michal Marek 
Link: http://lkml.kernel.org/r/1302607824-24699-1-git-send-email-mmarek@suse.cz
Signed-off-by: H. Peter Anvin

x86, setup: When probing memory with e801, use ax/bx as a pair

2011-04-25T21:52:37+00:00

When we use BIOS function e801 to probe memory, we should use ax/bx
(or cx/dx) as a pair, not mix and match.  This was a typo during the
translation from assembly code, and breaks at least one set of
machines in the field (which return cx = dx = 0).

Reported-and-tested-by: Chris Samuel 
Fix-proposed-by: Thomas Meyer 
Link: http://lkml.kernel.org/r/1303566747.12067.10.camel@localhost.localdomain

x86, build: Make sure mkpiggy fails on read error

2011-03-02T00:32:03+00:00

Ensure build doesn't silently continue despite read failure,
addressing a warning due to the unchecked call.

Signed-off-by: Daniel J Blueman 
LKML-Reference: 
Signed-off-by: H. Peter Anvin

x86: support XZ-compressed kernel

2011-01-13T16:03:25+00:00

This integrates the XZ decompression code to the x86 pre-boot code.

mkpiggy.c is updated to reserve about 32 KiB more buffer safety margin for
kernel decompression.  It is done unconditionally for all decompressors to
keep the code simpler.

The XZ decompressor needs around 30 KiB of heap, so the heap size is
increased to 32 KiB on both x86-32 and x86-64.

Documentation/x86/boot.txt is updated to list the XZ magic number.

With the x86 BCJ filter in XZ, XZ-compressed x86 kernel tends to be a few
percent smaller than the equivalent LZMA-compressed kernel.

Signed-off-by: Lasse Collin 
Cc: "H. Peter Anvin" 
Cc: Alain Knaff 
Cc: Albin Tonnerre 
Cc: Phillip Lougher 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

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

2011-01-06T18:56:02+00:00

* 'x86-cpu-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip:
  x86: Fix included-by file reference comments
  x86, cpu: Only CPU features determine NX capabilities
  x86, cpu: Call verify_cpu during 32bit CPU startup
  x86, cpu: Clear XD_DISABLED flag on Intel to regain NX
  x86, cpu: Rename verify_cpu_64.S to verify_cpu.S

x86-32: Make sure we can map all of lowmem if we need to

2010-12-17T03:11:09+00:00

A relocatable kernel can be anywhere in lowmem -- and in the case of a
kdump kernel, is likely to be fairly high.  Since the early page
tables map everything from address zero up we need to make sure we
allocate enough brk that we can map all of lowmem if we need to.

Reported-by: Stanislaw Gruszka 
Signed-off-by: H. Peter Anvin 
Tested-by: Yinghai Lu 
LKML-Reference: <4D0AD3ED.8070607@kernel.org>