2007-07-11 23:18:54 +04:00
/ *
* header. S
*
* Copyright ( C ) 1 9 9 1 , 1 9 9 2 L i n u s T o r v a l d s
*
* Based o n b o o t s e c t . S a n d s e t u p . S
* modified b y m o r e p e o p l e t h a n c a n b e c o u n t e d
*
* Rewritten a s a c o m m o n f i l e b y H . P e t e r A n v i n ( A p r 2 0 0 7 )
*
* BIG F A T N O T E : W e ' r e i n r e a l m o d e u s i n g 6 4 k s e g m e n t s . T h e r e f o r e s e g m e n t
* addresses m u s t b e m u l t i p l i e d b y 1 6 t o o b t a i n t h e i r r e s p e c t i v e l i n e a r
* addresses. T o a v o i d c o n f u s i o n , l i n e a r a d d r e s s e s a r e w r i t t e n u s i n g l e a d i n g
* hex w h i l e s e g m e n t a d d r e s s e s a r e w r i t t e n a s s e g m e n t : o f f s e t .
*
* /
# include < a s m / s e g m e n t . h >
2009-10-18 02:52:28 +04:00
# include < g e n e r a t e d / u t s r e l e a s e . h >
2007-07-11 23:18:54 +04:00
# include < a s m / b o o t . h >
2009-02-13 22:14:01 +03:00
# include < a s m / p a g e _ t y p e s . h >
2007-07-11 23:18:54 +04:00
# include < a s m / s e t u p . h >
2013-01-27 22:43:28 +04:00
# include < a s m / b o o t p a r a m . h >
2007-07-11 23:18:54 +04:00
# include " b o o t . h "
2009-05-12 01:21:12 +04:00
# include " v o f f s e t . h "
# include " z o f f s e t . h "
2007-07-11 23:18:54 +04:00
BOOTSEG = 0 x07 C 0 / * o r i g i n a l a d d r e s s o f b o o t - s e c t o r * /
2009-03-11 20:55:33 +03:00
SYSSEG = 0 x10 0 0 / * h i s t o r i c a l l o a d a d d r e s s > > 4 * /
2007-07-11 23:18:54 +04:00
# ifndef S V G A _ M O D E
# define S V G A _ M O D E A S K _ V G A
# endif
# ifndef R O O T _ R D O N L Y
# define R O O T _ R D O N L Y 1
# endif
.code16
.section " .bstext " , " ax"
.global bootsect_start
bootsect_start :
x86, efi: EFI boot stub support
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 <mikew@google.com>
Cc: Matthew Garrett <mjg@redhat.com>
Tested-by: Henrik Rydberg <rydberg@euromail.se>
Signed-off-by: Matt Fleming <matt.fleming@intel.com>
Link: http://lkml.kernel.org/r/1321383097.2657.9.camel@mfleming-mobl1.ger.corp.intel.com
Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
2011-12-13 01:27:52 +04:00
# ifdef C O N F I G _ E F I _ S T U B
# " MZ" , M S - D O S h e a d e r
.byte 0x4d
.byte 0x5a
# endif
2007-07-11 23:18:54 +04:00
# Normalize t h e s t a r t a d d r e s s
ljmp $ B O O T S E G , $ s t a r t 2
start2 :
movw % c s , % a x
movw % a x , % d s
movw % a x , % e s
movw % a x , % s s
xorw % s p , % s p
sti
cld
movw $ b u g g e r _ o f f _ m s g , % s i
msg_loop :
lodsb
andb % a l , % a l
jz b s _ d i e
movb $ 0 x e , % a h
movw $ 7 , % b x
int $ 0 x10
jmp m s g _ l o o p
bs_die :
# Allow t h e u s e r t o p r e s s a k e y , t h e n r e b o o t
xorw % a x , % a x
int $ 0 x16
int $ 0 x19
# int 0 x19 s h o u l d n e v e r r e t u r n . I n c a s e i t d o e s a n y w a y ,
# invoke t h e B I O S r e s e t c o d e . . .
ljmp $ 0 x f00 0 ,$ 0 x f f f0
x86, efi: EFI boot stub support
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 <mikew@google.com>
Cc: Matthew Garrett <mjg@redhat.com>
Tested-by: Henrik Rydberg <rydberg@euromail.se>
Signed-off-by: Matt Fleming <matt.fleming@intel.com>
Link: http://lkml.kernel.org/r/1321383097.2657.9.camel@mfleming-mobl1.ger.corp.intel.com
Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
2011-12-13 01:27:52 +04:00
# ifdef C O N F I G _ E F I _ S T U B
.org 0x3c
#
# Offset t o t h e P E h e a d e r .
#
.long pe_header
# endif / * C O N F I G _ E F I _ S T U B * /
2007-07-11 23:18:54 +04:00
.section " .bsdata " , " a"
bugger_off_msg :
2014-07-10 15:26:20 +04:00
.ascii " Use a b o o t l o a d e r . \ r \ n "
2007-07-11 23:18:54 +04:00
.ascii " \ n"
2014-07-10 15:26:20 +04:00
.ascii " Remove d i s k a n d p r e s s a n y k e y t o r e b o o t . . . \ r \ n "
2007-07-11 23:18:54 +04:00
.byte 0
x86, efi: EFI boot stub support
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 <mikew@google.com>
Cc: Matthew Garrett <mjg@redhat.com>
Tested-by: Henrik Rydberg <rydberg@euromail.se>
Signed-off-by: Matt Fleming <matt.fleming@intel.com>
Link: http://lkml.kernel.org/r/1321383097.2657.9.camel@mfleming-mobl1.ger.corp.intel.com
Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
2011-12-13 01:27:52 +04:00
# ifdef C O N F I G _ E F I _ S T U B
pe_header :
.ascii " PE"
.word 0
coff_header :
# ifdef C O N F I G _ X 8 6 _ 3 2
.word 0x14c # i3 8 6
# else
.word 0x8664 # x8 6 - 6 4
# endif
2014-07-10 15:26:20 +04:00
.word 4 # nr_ s e c t i o n s
x86, efi: EFI boot stub support
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 <mikew@google.com>
Cc: Matthew Garrett <mjg@redhat.com>
Tested-by: Henrik Rydberg <rydberg@euromail.se>
Signed-off-by: Matt Fleming <matt.fleming@intel.com>
Link: http://lkml.kernel.org/r/1321383097.2657.9.camel@mfleming-mobl1.ger.corp.intel.com
Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
2011-12-13 01:27:52 +04:00
.long 0 # TimeDateStamp
.long 0 # PointerToSymbolTable
.long 1 # NumberOfSymbols
.word section_table - optional_ h e a d e r # S i z e O f O p t i o n a l H e a d e r
# ifdef C O N F I G _ X 8 6 _ 3 2
.word 0x306 # Characteristics.
# IMAGE_ F I L E _ 3 2 B I T _ M A C H I N E |
# IMAGE_ F I L E _ D E B U G _ S T R I P P E D |
# IMAGE_ F I L E _ E X E C U T A B L E _ I M A G E |
# IMAGE_ F I L E _ L I N E _ N U M S _ S T R I P P E D
# else
.word 0x206 # Characteristics
# IMAGE_ F I L E _ D E B U G _ S T R I P P E D |
# IMAGE_ F I L E _ E X E C U T A B L E _ I M A G E |
# IMAGE_ F I L E _ L I N E _ N U M S _ S T R I P P E D
# endif
optional_header :
# ifdef C O N F I G _ X 8 6 _ 3 2
.word 0x10b # PE3 2 f o r m a t
# else
.word 0x20b # PE3 2 + f o r m a t
# endif
.byte 0x02 # MajorLinkerVersion
.byte 0x14 # MinorLinkerVersion
# Filled i n b y b u i l d . c
.long 0 # SizeOfCode
.long 0 # SizeOfInitializedData
.long 0 # SizeOfUninitializedData
# Filled i n b y b u i l d . c
.long 0x0000 # AddressOfEntryPoint
2012-03-23 20:35:05 +04:00
.long 0x0200 # BaseOfCode
x86, efi: EFI boot stub support
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 <mikew@google.com>
Cc: Matthew Garrett <mjg@redhat.com>
Tested-by: Henrik Rydberg <rydberg@euromail.se>
Signed-off-by: Matt Fleming <matt.fleming@intel.com>
Link: http://lkml.kernel.org/r/1321383097.2657.9.camel@mfleming-mobl1.ger.corp.intel.com
Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
2011-12-13 01:27:52 +04:00
# ifdef C O N F I G _ X 8 6 _ 3 2
.long 0 # data
# endif
extra_header_fields :
# ifdef C O N F I G _ X 8 6 _ 3 2
.long 0 # ImageBase
# else
.quad 0 # ImageBase
# endif
2015-08-07 11:36:56 +03:00
.long 0x20 # SectionAlignment
2012-06-07 20:05:21 +04:00
.long 0x20 # FileAlignment
x86, efi: EFI boot stub support
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 <mikew@google.com>
Cc: Matthew Garrett <mjg@redhat.com>
Tested-by: Henrik Rydberg <rydberg@euromail.se>
Signed-off-by: Matt Fleming <matt.fleming@intel.com>
Link: http://lkml.kernel.org/r/1321383097.2657.9.camel@mfleming-mobl1.ger.corp.intel.com
Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
2011-12-13 01:27:52 +04:00
.word 0 # MajorOperatingSystemVersion
.word 0 # MinorOperatingSystemVersion
.word 0 # MajorImageVersion
.word 0 # MinorImageVersion
.word 0 # MajorSubsystemVersion
.word 0 # MinorSubsystemVersion
.long 0 # Win3 2 V e r s i o n V a l u e
#
# The s i z e o f t h e b z I m a g e i s w r i t t e n i n t o o l s / b u i l d . c
#
.long 0 # SizeOfImage
.long 0x200 # SizeOfHeaders
.long 0 # CheckSum
.word 0xa # Subsystem ( E F I a p p l i c a t i o n )
.word 0 # DllCharacteristics
# ifdef C O N F I G _ X 8 6 _ 3 2
.long 0 # SizeOfStackReserve
.long 0 # SizeOfStackCommit
.long 0 # SizeOfHeapReserve
.long 0 # SizeOfHeapCommit
# else
.quad 0 # SizeOfStackReserve
.quad 0 # SizeOfStackCommit
.quad 0 # SizeOfHeapReserve
.quad 0 # SizeOfHeapCommit
# endif
.long 0 # LoaderFlags
2012-03-23 20:35:06 +04:00
.long 0x6 # NumberOfRvaAndSizes
x86, efi: EFI boot stub support
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 <mikew@google.com>
Cc: Matthew Garrett <mjg@redhat.com>
Tested-by: Henrik Rydberg <rydberg@euromail.se>
Signed-off-by: Matt Fleming <matt.fleming@intel.com>
Link: http://lkml.kernel.org/r/1321383097.2657.9.camel@mfleming-mobl1.ger.corp.intel.com
Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
2011-12-13 01:27:52 +04:00
.quad 0 # ExportTable
.quad 0 # ImportTable
.quad 0 # ResourceTable
.quad 0 # ExceptionTable
.quad 0 # CertificationTable
.quad 0 # BaseRelocationTable
# Section t a b l e
section_table :
2012-06-07 20:05:21 +04:00
#
# The o f f s e t & s i z e f i e l d s a r e f i l l e d i n b y b u i l d . c .
#
.ascii " .setup "
x86, efi: EFI boot stub support
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 <mikew@google.com>
Cc: Matthew Garrett <mjg@redhat.com>
Tested-by: Henrik Rydberg <rydberg@euromail.se>
Signed-off-by: Matt Fleming <matt.fleming@intel.com>
Link: http://lkml.kernel.org/r/1321383097.2657.9.camel@mfleming-mobl1.ger.corp.intel.com
Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
2011-12-13 01:27:52 +04:00
.byte 0
.byte 0
.long 0
.long 0x0 # startup_ { 3 2 ,6 4 }
.long 0 # Size o f i n i t i a l i z e d d a t a
# on d i s k
.long 0x0 # startup_ { 3 2 ,6 4 }
.long 0 # PointerToRelocations
.long 0 # PointerToLineNumbers
.word 0 # NumberOfRelocations
.word 0 # NumberOfLineNumbers
.long 0x60500020 # Characteristics ( s e c t i o n f l a g s )
#
# The E F I a p p l i c a t i o n l o a d e r r e q u i r e s a r e l o c a t i o n s e c t i o n
2012-06-07 20:05:21 +04:00
# because E F I a p p l i c a t i o n s m u s t b e r e l o c a t a b l e . T h e . r e l o c
# offset & s i z e f i e l d s a r e f i l l e d i n b y b u i l d . c .
x86, efi: EFI boot stub support
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 <mikew@google.com>
Cc: Matthew Garrett <mjg@redhat.com>
Tested-by: Henrik Rydberg <rydberg@euromail.se>
Signed-off-by: Matt Fleming <matt.fleming@intel.com>
Link: http://lkml.kernel.org/r/1321383097.2657.9.camel@mfleming-mobl1.ger.corp.intel.com
Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
2011-12-13 01:27:52 +04:00
#
.ascii " .reloc "
.byte 0
.byte 0
2012-03-23 20:35:04 +04:00
.long 0
.long 0
.long 0 # SizeOfRawData
.long 0 # PointerToRawData
x86, efi: EFI boot stub support
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 <mikew@google.com>
Cc: Matthew Garrett <mjg@redhat.com>
Tested-by: Henrik Rydberg <rydberg@euromail.se>
Signed-off-by: Matt Fleming <matt.fleming@intel.com>
Link: http://lkml.kernel.org/r/1321383097.2657.9.camel@mfleming-mobl1.ger.corp.intel.com
Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
2011-12-13 01:27:52 +04:00
.long 0 # PointerToRelocations
.long 0 # PointerToLineNumbers
.word 0 # NumberOfRelocations
.word 0 # NumberOfLineNumbers
.long 0x42100040 # Characteristics ( s e c t i o n f l a g s )
2012-06-07 20:05:21 +04:00
#
# The o f f s e t & s i z e f i e l d s a r e f i l l e d i n b y b u i l d . c .
#
.ascii " .text "
.byte 0
.byte 0
.byte 0
.long 0
.long 0x0 # startup_ { 3 2 ,6 4 }
.long 0 # Size o f i n i t i a l i z e d d a t a
# on d i s k
.long 0x0 # startup_ { 3 2 ,6 4 }
.long 0 # PointerToRelocations
.long 0 # PointerToLineNumbers
.word 0 # NumberOfRelocations
.word 0 # NumberOfLineNumbers
.long 0x60500020 # Characteristics ( s e c t i o n f l a g s )
2014-07-10 15:26:20 +04:00
#
# The o f f s e t & s i z e f i e l d s a r e f i l l e d i n b y b u i l d . c .
#
.ascii " .bss "
.byte 0
.byte 0
.byte 0
.byte 0
.long 0
.long 0x0
.long 0 # Size o f i n i t i a l i z e d d a t a
# on d i s k
.long 0x0
.long 0 # PointerToRelocations
.long 0 # PointerToLineNumbers
.word 0 # NumberOfRelocations
.word 0 # NumberOfLineNumbers
.long 0xc8000080 # Characteristics ( s e c t i o n f l a g s )
x86, efi: EFI boot stub support
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 <mikew@google.com>
Cc: Matthew Garrett <mjg@redhat.com>
Tested-by: Henrik Rydberg <rydberg@euromail.se>
Signed-off-by: Matt Fleming <matt.fleming@intel.com>
Link: http://lkml.kernel.org/r/1321383097.2657.9.camel@mfleming-mobl1.ger.corp.intel.com
Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
2011-12-13 01:27:52 +04:00
# endif / * C O N F I G _ E F I _ S T U B * /
2007-07-11 23:18:54 +04:00
# Kernel a t t r i b u t e s ; used by setup. This is part 1 of the
# header, f r o m t h e o l d b o o t s e c t o r .
.section " .header " , " a"
2013-01-27 22:43:28 +04:00
.globl sentinel
sentinel : .byte 0xff , 0 xff / * U s e d t o d e t e c t b r o k e n l o a d e r s * /
2007-07-11 23:18:54 +04:00
.globl hdr
hdr :
2009-03-11 20:55:33 +03:00
setup_sects : .byte 0 /* Filled in by build.c */
2007-07-11 23:18:54 +04:00
root_flags : .word R O O T _ R D O N L Y
2009-03-11 20:55:33 +03:00
syssize : .long 0 /* Filled in by build.c */
ram_size : .word 0 /* Obsolete */
2007-07-11 23:18:54 +04:00
vid_mode : .word S V G A _ M O D E
2009-03-11 20:55:33 +03:00
root_dev : .word 0 /* Filled in by build.c */
2007-07-11 23:18:54 +04:00
boot_flag : .word 0xAA55
# offset 5 1 2 , e n t r y p o i n t
.globl _start
_start :
# Explicitly e n t e r t h i s a s b y t e s , o r t h e a s s e m b l e r
# tries t o g e n e r a t e a 3 - b y t e j u m p h e r e , w h i c h c a u s e s
# everything e l s e t o p u s h o f f t o t h e w r o n g o f f s e t .
.byte 0xeb # short ( 2 - b y t e ) j u m p
.byte start_ o f _ s e t u p - 1 f
1 :
# Part 2 o f t h e h e a d e r , f r o m t h e o l d s e t u p . S
.ascii " HdrS" # h e a d e r s i g n a t u r e
2014-01-10 22:52:06 +04:00
.word 0x020d # header v e r s i o n n u m b e r ( > = 0 x01 0 5 )
2007-07-11 23:18:54 +04:00
# or e l s e o l d l o a d l i n - 1 . 5 w i l l f a i l )
.globl realmode_swtch
realmode_swtch : .word 0 , 0 # default_ s w i t c h , S E T U P S E G
2009-03-11 20:55:33 +03:00
start_sys_seg : .word S Y S S E G # o b s o l e t e a n d m e a n i n g l e s s , b u t j u s t
# in c a s e s o m e t h i n g d e c i d e d t o " u s e " i t
2007-07-11 23:18:54 +04:00
.word kernel_ v e r s i o n - 5 1 2 # p o i n t i n g t o k e r n e l v e r s i o n s t r i n g
# above s e c t i o n o f h e a d e r i s c o m p a t i b l e
# with l o a d l i n - 1 . 5 ( h e a d e r v1 . 5 ) . D o n ' t
# change i t .
2009-03-11 20:55:33 +03:00
type_of_loader : .byte 0 # 0 means a n c i e n t b o o t l o a d e r , n e w e r
# bootloaders k n o w t o c h a n g e t h i s .
2011-08-15 04:02:26 +04:00
# See D o c u m e n t a t i o n / x86 / b o o t . t x t f o r
2007-07-11 23:18:54 +04:00
# assigned i d s
# flags, u n u s e d b i t s m u s t b e z e r o ( R F U ) b i t w i t h i n l o a d f l a g s
loadflags :
2013-01-27 22:43:28 +04:00
.byte LOADED_HIGH # The k e r n e l i s t o b e l o a d e d h i g h
2007-07-11 23:18:54 +04:00
setup_move_size : .word 0x8000 # size t o m o v e , w h e n s e t u p i s n o t
# loaded a t 0 x90 0 0 0 . W e w i l l m o v e s e t u p
# to 0 x90 0 0 0 t h e n j u s t b e f o r e j u m p i n g
# into t h e k e r n e l . H o w e v e r , o n l y t h e
# loader k n o w s h o w m u c h d a t a b e h i n d
# us a l s o n e e d s t o b e l o a d e d .
code32_start : # here l o a d e r s c a n p u t a d i f f e r e n t
# start a d d r e s s f o r 3 2 - b i t c o d e .
.long 0x100000 # 0 x1 0 0 0 0 0 = d e f a u l t f o r b i g k e r n e l
ramdisk_image : .long 0 # address o f l o a d e d r a m d i s k i m a g e
# Here t h e l o a d e r p u t s t h e 3 2 - b i t
# address w h e r e i t l o a d e d t h e i m a g e .
# This o n l y w i l l b e r e a d b y t h e k e r n e l .
ramdisk_size : .long 0 # its s i z e i n b y t e s
bootsect_kludge :
.long 0 # obsolete
2007-10-26 03:11:33 +04:00
heap_end_ptr : .word _ e n d + S T A C K _ S I Z E - 512
# ( Header v e r s i o n 0 x02 0 1 o r l a t e r )
2007-07-11 23:18:54 +04:00
# space f r o m h e r e ( e x c l u s i v e ) d o w n t o
# end o f s e t u p c o d e c a n b e u s e d b y s e t u p
# for l o c a l h e a p p u r p o s e s .
2009-05-08 03:54:11 +04:00
ext_loader_ver :
.byte 0 # Extended b o o t l o a d e r v e r s i o n
ext_loader_type :
.byte 0 # Extended b o o t l o a d e r t y p e
2007-07-11 23:18:54 +04:00
cmd_line_ptr : .long 0 # ( Header v e r s i o n 0 x02 0 2 o r l a t e r )
# If n o n z e r o , a 3 2 - b i t p o i n t e r
# to t h e k e r n e l c o m m a n d l i n e .
# The c o m m a n d l i n e s h o u l d b e
# located b e t w e e n t h e s t a r t o f
# setup a n d t h e e n d o f l o w
# memory ( 0 x a00 0 0 ) , o r i t m a y
# get o v e r w r i t t e n b e f o r e i t
# gets r e a d . I f t h i s f i e l d i s
# used, t h e r e i s n o l o n g e r
# anything m a g i c a l a b o u t t h e
# 0 x9 0 0 0 0 s e g m e n t ; the setup
# can b e l o c a t e d a n y w h e r e i n
# low m e m o r y 0 x10 0 0 0 o r h i g h e r .
2014-03-12 18:13:02 +04:00
initrd_addr_max : .long 0x7fffffff
2007-07-11 23:18:54 +04:00
# ( Header v e r s i o n 0 x02 0 3 o r l a t e r )
# The h i g h e s t s a f e a d d r e s s f o r
# the c o n t e n t s o f a n i n i t r d
2008-01-30 15:32:51 +03:00
# The c u r r e n t k e r n e l a l l o w s u p t o 4 G B ,
# but l e a v e i t a t 2 G B t o a v o i d
# possible b o o t l o a d e r b u g s .
2007-07-11 23:18:54 +04:00
kernel_alignment : .long C O N F I G _ P H Y S I C A L _ A L I G N # p h y s i c a l a d d r a l i g n m e n t
# required f o r p r o t e c t e d m o d e
# kernel
# ifdef C O N F I G _ R E L O C A T A B L E
relocatable_kernel : .byte 1
# else
relocatable_kernel : .byte 0
# endif
2009-05-12 02:56:08 +04:00
min_alignment : .byte M I N _ K E R N E L _ A L I G N _ L G 2 # minimum a l i g n m e n t
2013-01-27 22:43:28 +04:00
xloadflags :
# ifdef C O N F I G _ X 8 6 _ 6 4
# define X L F 0 X L F _ K E R N E L _ 6 4 / * 6 4 - b i t k e r n e l * /
# else
# define X L F 0 0
# endif
2013-01-29 08:16:44 +04:00
2014-06-07 15:26:20 +04:00
# if d e f i n e d ( C O N F I G _ R E L O C A T A B L E ) & & d e f i n e d ( C O N F I G _ X 8 6 _ 6 4 )
2013-01-29 08:16:44 +04:00
/* kernel/boot_param/ramdisk could be loaded above 4g */
# define X L F 1 X L F _ C A N _ B E _ L O A D E D _ A B O V E _ 4 G
# else
# define X L F 1 0
# endif
2013-01-27 22:43:28 +04:00
# ifdef C O N F I G _ E F I _ S T U B
2014-01-10 22:52:06 +04:00
# ifdef C O N F I G _ E F I _ M I X E D
# define X L F 2 3 ( X L F _ E F I _ H A N D O V E R _ 3 2 | X L F _ E F I _ H A N D O V E R _ 6 4 )
2013-01-27 22:43:28 +04:00
# else
2014-01-10 22:52:06 +04:00
# ifdef C O N F I G _ X 8 6 _ 6 4
# define X L F 2 3 X L F _ E F I _ H A N D O V E R _ 6 4 / * 6 4 - b i t E F I h a n d o v e r o k * /
# else
# define X L F 2 3 X L F _ E F I _ H A N D O V E R _ 3 2 / * 3 2 - b i t E F I h a n d o v e r o k * /
# endif
2013-01-27 22:43:28 +04:00
# endif
# else
# define X L F 2 3 0
# endif
2013-12-20 14:02:20 +04:00
2015-09-10 01:38:55 +03:00
# if d e f i n e d ( C O N F I G _ X 8 6 _ 6 4 ) & & d e f i n e d ( C O N F I G _ E F I ) & & d e f i n e d ( C O N F I G _ K E X E C _ C O R E )
2013-12-20 14:02:20 +04:00
# define X L F 4 X L F _ E F I _ K E X E C
# else
# define X L F 4 0
# endif
.word XLF0 | XLF1 | X L F 2 3 | X L F 4
2007-07-11 23:18:54 +04:00
cmdline_size : .long C O M M A N D _ L I N E _ S I Z E - 1 # length o f t h e c o m m a n d l i n e ,
# added w i t h b o o t p r o t o c o l
# version 2 . 0 6
2007-10-22 03:41:35 +04:00
hardware_subarch : .long 0 # subarchitecture, a d d e d w i t h 2 . 0 7
# default t o 0 f o r n o r m a l x86 P C
hardware_subarch_data : .quad 0
2009-05-12 01:21:12 +04:00
payload_offset : .long Z O _ i n p u t _ d a t a
payload_length : .long Z O _ z _ i n p u t _ l e n
2008-02-13 23:54:58 +03:00
2008-03-28 05:49:44 +03:00
setup_data : .quad 0 # 6 4 - bit p h y s i c a l p o i n t e r t o
# single l i n k e d l i s t o f
# struct s e t u p _ d a t a
2009-05-12 02:56:08 +04:00
pref_address : .quad L O A D _ P H Y S I C A L _ A D D R # p r e f e r r e d l o a d a d d r
x86/KASLR: Update description for decompressor worst case size
The comment that describes the analysis for the size of the decompressor
code only took gzip into account (there are currently 6 other decompressors
that could be used). The actual z_extract_offset calculation in code was
already handling the correct maximum size, but this documentation hadn't
been updated. This updates the documentation, fixes several typos, moves
the comment to header.S, updates references, and adds a note at the end
of the decompressor include list to remind us about updating the comment
in the future.
(Instead of moving the comment to mkpiggy.c, where the calculation
is currently happening, it is being moved to header.S because
the calculations in mkpiggy.c will be removed in favor of header.S
calculations in a following patch, and it seemed like overkill to move
the giant comment twice, especially when there's already reference to
z_extract_offset in header.S.)
Signed-off-by: Baoquan He <bhe@redhat.com>
[ Rewrote changelog, cleaned up comment style, moved comments around. ]
Signed-off-by: Kees Cook <keescook@chromium.org>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Andrey Ryabinin <aryabinin@virtuozzo.com>
Cc: Andy Lutomirski <luto@amacapital.net>
Cc: Andy Lutomirski <luto@kernel.org>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Borislav Petkov <bp@suse.de>
Cc: Brian Gerst <brgerst@gmail.com>
Cc: Denys Vlasenko <dvlasenk@redhat.com>
Cc: Dmitry Vyukov <dvyukov@google.com>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: H.J. Lu <hjl.tools@gmail.com>
Cc: Josh Poimboeuf <jpoimboe@redhat.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Yinghai Lu <yinghai@kernel.org>
Link: http://lkml.kernel.org/r/1461185746-8017-2-git-send-email-keescook@chromium.org
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2016-04-20 23:55:42 +03:00
#
# Getting t o p r o v a b l y s a f e i n - p l a c e d e c o m p r e s s i o n i s h a r d . W o r s t c a s e
# behaviours n e e d t o b e a n a l y z e d . H e r e l e t ' s t a k e t h e d e c o m p r e s s i o n o f
# a g z i p - c o m p r e s s e d k e r n e l a s e x a m p l e , t o i l l u s t r a t e i t :
#
# The f i l e l a y o u t o f g z i p c o m p r e s s e d k e r n e l i s :
#
# magic[ 2 ]
# method[ 1 ]
# flags[ 1 ]
# timestamp[ 4 ]
# extraflags[ 1 ]
# os[ 1 ]
# compressed d a t a b l o c k s [ N ]
# crc[ 4 ] o r i g _ l e n [ 4 ]
#
# . . . resulting i n + 1 8 b y t e s o v e r h e a d o f u n c o m p r e s s e d d a t a .
#
# ( For m o r e i n f o r m a t i o n , p l e a s e r e f e r t o R F C 1 9 5 1 a n d R F C 1 9 5 2 . )
#
# Files d i v i d e d i n t o b l o c k s
# 1 bit ( l a s t b l o c k f l a g )
# 2 bits ( b l o c k t y p e )
#
# 1 block o c c u r s e v e r y 3 2 K - 1 b y t e s o r w h e n t h e r e 5 0 % c o m p r e s s i o n
# has b e e n a c h i e v e d . T h e s m a l l e s t b l o c k t y p e e n c o d i n g i s a l w a y s u s e d .
#
# stored :
# 3 2 bits l e n g t h i n b y t e s .
#
# fixed :
# magic f i x e d t r e e .
# symbols.
#
# dynamic :
# dynamic t r e e e n c o d i n g .
# symbols.
#
#
# The b u f f e r f o r d e c o m p r e s s i o n i n p l a c e i s t h e l e n g t h o f t h e u n c o m p r e s s e d
# data, p l u s a s m a l l a m o u n t e x t r a t o k e e p t h e a l g o r i t h m s a f e . T h e
# compressed d a t a i s p l a c e d a t t h e e n d o f t h e b u f f e r . T h e o u t p u t p o i n t e r
# is p l a c e d a t t h e s t a r t o f t h e b u f f e r a n d t h e i n p u t p o i n t e r i s p l a c e d
# where t h e c o m p r e s s e d d a t a s t a r t s . P r o b l e m s w i l l o c c u r w h e n t h e o u t p u t
# pointer o v e r r u n s t h e i n p u t p o i n t e r .
#
# The o u t p u t p o i n t e r c a n o n l y o v e r r u n t h e i n p u t p o i n t e r i f t h e i n p u t
# pointer i s m o v i n g f a s t e r t h a n t h e o u t p u t p o i n t e r . A c o n d i t i o n o n l y
# triggered b y d a t a w h o s e c o m p r e s s e d f o r m i s l a r g e r t h a n t h e u n c o m p r e s s e d
# form.
#
# The w o r s t c a s e a t t h e b l o c k l e v e l i s a g r o w t h o f t h e c o m p r e s s e d d a t a
# of 5 b y t e s p e r 3 2 7 6 7 b y t e s .
#
# The w o r s t c a s e i n t e r n a l t o a c o m p r e s s e d b l o c k i s v e r y h a r d t o f i g u r e .
# The w o r s t c a s e c a n a t l e a s t b e b o u n d e d b y h a v i n g o n e b i t t h a t r e p r e s e n t s
# 3 2 7 6 4 bytes a n d t h e n a l l o f t h e r e s t o f t h e b y t e s r e p r e s e n t i n g t h e v e r y
# very l a s t b y t e .
#
# All o f w h i c h i s e n o u g h t o c o m p u t e a n a m o u n t o f e x t r a d a t a t h a t i s r e q u i r e d
# to b e s a f e . T o a v o i d p r o b l e m s a t t h e b l o c k l e v e l a l l o c a t i n g 5 e x t r a b y t e s
# per 3 2 7 6 7 b y t e s o f d a t a i s s u f f i c i e n t . T o a v o i d p r o b l e m s i n t e r n a l t o a
# block a d d i n g a n e x t r a 3 2 7 6 7 b y t e s ( t h e w o r s t c a s e u n c o m p r e s s e d b l o c k s i z e )
# is s u f f i c i e n t , t o e n s u r e t h a t i n t h e w o r s t c a s e t h e d e c o m p r e s s e d d a t a f o r
# block w i l l s t o p t h e b y t e b e f o r e t h e c o m p r e s s e d d a t a f o r a b l o c k b e g i n s .
# To a v o i d p r o b l e m s w i t h t h e c o m p r e s s e d d a t a ' s m e t a i n f o r m a t i o n a n e x t r a 1 8
# bytes a r e n e e d e d . L e a d i n g t o t h e f o r m u l a :
#
x86/boot: Calculate decompression size during boot not build
Currently z_extract_offset is calculated in boot/compressed/mkpiggy.c.
This doesn't work well because mkpiggy.c doesn't know the details of the
decompressor in use. As a result, it can only make an estimation, which
has risks:
- output + output_len (VO) could be much bigger than input + input_len
(ZO). In this case, the decompressed kernel plus relocs could overwrite
the decompression code while it is running.
- The head code of ZO could be bigger than z_extract_offset. In this case
an overwrite could happen when the head code is running to move ZO to
the end of buffer. Though currently the size of the head code is very
small it's still a potential risk. Since there is no rule to limit the
size of the head code of ZO, it runs the risk of suddenly becoming a
(hard to find) bug.
Instead, this moves the z_extract_offset calculation into header.S, and
makes adjustments to be sure that the above two cases can never happen,
and further corrects the comments describing the calculations.
Since we have (in the previous patch) made ZO always be located against
the end of decompression buffer, z_extract_offset is only used here to
calculate an appropriate buffer size (INIT_SIZE), and is not longer used
elsewhere. As such, it can be removed from voffset.h.
Additionally clean up #if/#else #define to improve readability.
Signed-off-by: Yinghai Lu <yinghai@kernel.org>
Signed-off-by: Baoquan He <bhe@redhat.com>
[ Rewrote the changelog and comments. ]
Signed-off-by: Kees Cook <keescook@chromium.org>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Andy Lutomirski <luto@amacapital.net>
Cc: Andy Lutomirski <luto@kernel.org>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Brian Gerst <brgerst@gmail.com>
Cc: Dave Young <dyoung@redhat.com>
Cc: Denys Vlasenko <dvlasenk@redhat.com>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Vivek Goyal <vgoyal@redhat.com>
Cc: lasse.collin@tukaani.org
Link: http://lkml.kernel.org/r/1461888548-32439-4-git-send-email-keescook@chromium.org
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2016-04-29 03:09:05 +03:00
# extra_ b y t e s = ( u n c o m p r e s s e d _ s i z e > > 1 2 ) + 3 2 7 6 8 + 1 8
x86/KASLR: Update description for decompressor worst case size
The comment that describes the analysis for the size of the decompressor
code only took gzip into account (there are currently 6 other decompressors
that could be used). The actual z_extract_offset calculation in code was
already handling the correct maximum size, but this documentation hadn't
been updated. This updates the documentation, fixes several typos, moves
the comment to header.S, updates references, and adds a note at the end
of the decompressor include list to remind us about updating the comment
in the future.
(Instead of moving the comment to mkpiggy.c, where the calculation
is currently happening, it is being moved to header.S because
the calculations in mkpiggy.c will be removed in favor of header.S
calculations in a following patch, and it seemed like overkill to move
the giant comment twice, especially when there's already reference to
z_extract_offset in header.S.)
Signed-off-by: Baoquan He <bhe@redhat.com>
[ Rewrote changelog, cleaned up comment style, moved comments around. ]
Signed-off-by: Kees Cook <keescook@chromium.org>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Andrey Ryabinin <aryabinin@virtuozzo.com>
Cc: Andy Lutomirski <luto@amacapital.net>
Cc: Andy Lutomirski <luto@kernel.org>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Borislav Petkov <bp@suse.de>
Cc: Brian Gerst <brgerst@gmail.com>
Cc: Denys Vlasenko <dvlasenk@redhat.com>
Cc: Dmitry Vyukov <dvyukov@google.com>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: H.J. Lu <hjl.tools@gmail.com>
Cc: Josh Poimboeuf <jpoimboe@redhat.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Yinghai Lu <yinghai@kernel.org>
Link: http://lkml.kernel.org/r/1461185746-8017-2-git-send-email-keescook@chromium.org
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2016-04-20 23:55:42 +03:00
#
# Adding 8 b y t e s p e r 3 2 K i s a b i t e x c e s s i v e b u t m u c h e a s i e r t o c a l c u l a t e .
# Adding 3 2 7 6 8 i n s t e a d o f 3 2 7 6 7 j u s t m a k e s f o r r o u n d n u m b e r s .
#
# Above a n a l y s i s i s f o r d e c o m p r e s s i n g g z i p c o m p r e s s e d k e r n e l o n l y . U p t o
# now 6 d i f f e r e n t d e c o m p r e s s o r a r e s u p p o r t e d a l l t o g e t h e r . A n d a m o n g t h e m
# xz s t o r e s d a t a i n c h u n k s a n d h a s m a x i m u m c h u n k o f 6 4 K . H e n c e s a f e t y
# margin s h o u l d b e u p d a t e d t o c o v e r a l l d e c o m p r e s s o r s s o t h a t w e d o n ' t
# need t o d e a l w i t h e a c h o f t h e m s e p a r a t e l y . P l e a s e c h e c k
# the d e s c r i p t i o n i n l i b / d e c o m p r e s s o r _ x x x . c f o r s p e c i f i c i n f o r m a t i o n .
#
# extra_ b y t e s = ( u n c o m p r e s s e d _ s i z e > > 1 2 ) + 6 5 5 3 6 + 1 2 8
x86/boot: Calculate decompression size during boot not build
Currently z_extract_offset is calculated in boot/compressed/mkpiggy.c.
This doesn't work well because mkpiggy.c doesn't know the details of the
decompressor in use. As a result, it can only make an estimation, which
has risks:
- output + output_len (VO) could be much bigger than input + input_len
(ZO). In this case, the decompressed kernel plus relocs could overwrite
the decompression code while it is running.
- The head code of ZO could be bigger than z_extract_offset. In this case
an overwrite could happen when the head code is running to move ZO to
the end of buffer. Though currently the size of the head code is very
small it's still a potential risk. Since there is no rule to limit the
size of the head code of ZO, it runs the risk of suddenly becoming a
(hard to find) bug.
Instead, this moves the z_extract_offset calculation into header.S, and
makes adjustments to be sure that the above two cases can never happen,
and further corrects the comments describing the calculations.
Since we have (in the previous patch) made ZO always be located against
the end of decompression buffer, z_extract_offset is only used here to
calculate an appropriate buffer size (INIT_SIZE), and is not longer used
elsewhere. As such, it can be removed from voffset.h.
Additionally clean up #if/#else #define to improve readability.
Signed-off-by: Yinghai Lu <yinghai@kernel.org>
Signed-off-by: Baoquan He <bhe@redhat.com>
[ Rewrote the changelog and comments. ]
Signed-off-by: Kees Cook <keescook@chromium.org>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Andy Lutomirski <luto@amacapital.net>
Cc: Andy Lutomirski <luto@kernel.org>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Brian Gerst <brgerst@gmail.com>
Cc: Dave Young <dyoung@redhat.com>
Cc: Denys Vlasenko <dvlasenk@redhat.com>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Vivek Goyal <vgoyal@redhat.com>
Cc: lasse.collin@tukaani.org
Link: http://lkml.kernel.org/r/1461888548-32439-4-git-send-email-keescook@chromium.org
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2016-04-29 03:09:05 +03:00
# define Z O _ z _ e x t r a _ b y t e s ( ( Z O _ z _ o u t p u t _ l e n > > 1 2 ) + 6 5 5 3 6 + 1 2 8 )
# if Z O _ z _ o u t p u t _ l e n > Z O _ z _ i n p u t _ l e n
# define Z O _ z _ e x t r a c t _ o f f s e t ( Z O _ z _ o u t p u t _ l e n + Z O _ z _ e x t r a _ b y t e s - \
ZO_ z _ i n p u t _ l e n )
# else
# define Z O _ z _ e x t r a c t _ o f f s e t Z O _ z _ e x t r a _ b y t e s
# endif
/ *
* The e x t r a c t _ o f f s e t h a s t o b e b i g g e r t h a n Z O h e a d s e c t i o n . O t h e r w i s e w h e n
* the h e a d c o d e i s r u n n i n g t o m o v e Z O t o t h e e n d o f t h e b u f f e r , i t w i l l
* overwrite t h e h e a d c o d e i t s e l f .
* /
# if ( Z O _ _ e h e a d - Z O _ s t a r t u p _ 3 2 ) > Z O _ z _ e x t r a c t _ o f f s e t
# define Z O _ z _ m i n _ e x t r a c t _ o f f s e t ( ( Z O _ _ e h e a d - Z O _ s t a r t u p _ 3 2 + 4 0 9 5 ) & ~ 4 0 9 5 )
# else
# define Z O _ z _ m i n _ e x t r a c t _ o f f s e t ( ( Z O _ z _ e x t r a c t _ o f f s e t + 4 0 9 5 ) & ~ 4 0 9 5 )
# endif
# define Z O _ I N I T _ S I Z E ( Z O _ _ e n d - Z O _ s t a r t u p _ 3 2 + Z O _ z _ m i n _ e x t r a c t _ o f f s e t )
2009-05-12 02:56:08 +04:00
# define V O _ I N I T _ S I Z E ( V O _ _ e n d - V O _ _ t e x t )
# if Z O _ I N I T _ S I Z E > V O _ I N I T _ S I Z E
x86/boot: Calculate decompression size during boot not build
Currently z_extract_offset is calculated in boot/compressed/mkpiggy.c.
This doesn't work well because mkpiggy.c doesn't know the details of the
decompressor in use. As a result, it can only make an estimation, which
has risks:
- output + output_len (VO) could be much bigger than input + input_len
(ZO). In this case, the decompressed kernel plus relocs could overwrite
the decompression code while it is running.
- The head code of ZO could be bigger than z_extract_offset. In this case
an overwrite could happen when the head code is running to move ZO to
the end of buffer. Though currently the size of the head code is very
small it's still a potential risk. Since there is no rule to limit the
size of the head code of ZO, it runs the risk of suddenly becoming a
(hard to find) bug.
Instead, this moves the z_extract_offset calculation into header.S, and
makes adjustments to be sure that the above two cases can never happen,
and further corrects the comments describing the calculations.
Since we have (in the previous patch) made ZO always be located against
the end of decompression buffer, z_extract_offset is only used here to
calculate an appropriate buffer size (INIT_SIZE), and is not longer used
elsewhere. As such, it can be removed from voffset.h.
Additionally clean up #if/#else #define to improve readability.
Signed-off-by: Yinghai Lu <yinghai@kernel.org>
Signed-off-by: Baoquan He <bhe@redhat.com>
[ Rewrote the changelog and comments. ]
Signed-off-by: Kees Cook <keescook@chromium.org>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Andy Lutomirski <luto@amacapital.net>
Cc: Andy Lutomirski <luto@kernel.org>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Brian Gerst <brgerst@gmail.com>
Cc: Dave Young <dyoung@redhat.com>
Cc: Denys Vlasenko <dvlasenk@redhat.com>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Vivek Goyal <vgoyal@redhat.com>
Cc: lasse.collin@tukaani.org
Link: http://lkml.kernel.org/r/1461888548-32439-4-git-send-email-keescook@chromium.org
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2016-04-29 03:09:05 +03:00
# define I N I T _ S I Z E Z O _ I N I T _ S I Z E
2009-05-12 02:56:08 +04:00
# else
x86/boot: Calculate decompression size during boot not build
Currently z_extract_offset is calculated in boot/compressed/mkpiggy.c.
This doesn't work well because mkpiggy.c doesn't know the details of the
decompressor in use. As a result, it can only make an estimation, which
has risks:
- output + output_len (VO) could be much bigger than input + input_len
(ZO). In this case, the decompressed kernel plus relocs could overwrite
the decompression code while it is running.
- The head code of ZO could be bigger than z_extract_offset. In this case
an overwrite could happen when the head code is running to move ZO to
the end of buffer. Though currently the size of the head code is very
small it's still a potential risk. Since there is no rule to limit the
size of the head code of ZO, it runs the risk of suddenly becoming a
(hard to find) bug.
Instead, this moves the z_extract_offset calculation into header.S, and
makes adjustments to be sure that the above two cases can never happen,
and further corrects the comments describing the calculations.
Since we have (in the previous patch) made ZO always be located against
the end of decompression buffer, z_extract_offset is only used here to
calculate an appropriate buffer size (INIT_SIZE), and is not longer used
elsewhere. As such, it can be removed from voffset.h.
Additionally clean up #if/#else #define to improve readability.
Signed-off-by: Yinghai Lu <yinghai@kernel.org>
Signed-off-by: Baoquan He <bhe@redhat.com>
[ Rewrote the changelog and comments. ]
Signed-off-by: Kees Cook <keescook@chromium.org>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Andy Lutomirski <luto@amacapital.net>
Cc: Andy Lutomirski <luto@kernel.org>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Brian Gerst <brgerst@gmail.com>
Cc: Dave Young <dyoung@redhat.com>
Cc: Denys Vlasenko <dvlasenk@redhat.com>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Vivek Goyal <vgoyal@redhat.com>
Cc: lasse.collin@tukaani.org
Link: http://lkml.kernel.org/r/1461888548-32439-4-git-send-email-keescook@chromium.org
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2016-04-29 03:09:05 +03:00
# define I N I T _ S I Z E V O _ I N I T _ S I Z E
2009-05-12 02:56:08 +04:00
# endif
x86/boot: Calculate decompression size during boot not build
Currently z_extract_offset is calculated in boot/compressed/mkpiggy.c.
This doesn't work well because mkpiggy.c doesn't know the details of the
decompressor in use. As a result, it can only make an estimation, which
has risks:
- output + output_len (VO) could be much bigger than input + input_len
(ZO). In this case, the decompressed kernel plus relocs could overwrite
the decompression code while it is running.
- The head code of ZO could be bigger than z_extract_offset. In this case
an overwrite could happen when the head code is running to move ZO to
the end of buffer. Though currently the size of the head code is very
small it's still a potential risk. Since there is no rule to limit the
size of the head code of ZO, it runs the risk of suddenly becoming a
(hard to find) bug.
Instead, this moves the z_extract_offset calculation into header.S, and
makes adjustments to be sure that the above two cases can never happen,
and further corrects the comments describing the calculations.
Since we have (in the previous patch) made ZO always be located against
the end of decompression buffer, z_extract_offset is only used here to
calculate an appropriate buffer size (INIT_SIZE), and is not longer used
elsewhere. As such, it can be removed from voffset.h.
Additionally clean up #if/#else #define to improve readability.
Signed-off-by: Yinghai Lu <yinghai@kernel.org>
Signed-off-by: Baoquan He <bhe@redhat.com>
[ Rewrote the changelog and comments. ]
Signed-off-by: Kees Cook <keescook@chromium.org>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Andy Lutomirski <luto@amacapital.net>
Cc: Andy Lutomirski <luto@kernel.org>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Brian Gerst <brgerst@gmail.com>
Cc: Dave Young <dyoung@redhat.com>
Cc: Denys Vlasenko <dvlasenk@redhat.com>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Vivek Goyal <vgoyal@redhat.com>
Cc: lasse.collin@tukaani.org
Link: http://lkml.kernel.org/r/1461888548-32439-4-git-send-email-keescook@chromium.org
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2016-04-29 03:09:05 +03:00
2009-05-12 02:56:08 +04:00
init_size : .long I N I T _ S I Z E # k e r n e l i n i t i a l i z a t i o n s i z e
2013-08-01 16:33:26 +04:00
handover_offset : .long 0 # Filled i n b y b u i l d . c
2009-05-12 02:56:08 +04:00
2007-07-11 23:18:54 +04:00
# End o f s e t u p h e a d e r ## # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # #
2009-04-02 05:08:28 +04:00
.section " .entrytext " , " ax"
2007-07-11 23:18:54 +04:00
start_of_setup :
# Force % e s = % d s
movw % d s , % a x
movw % a x , % e s
cld
2007-11-27 14:35:13 +03:00
# Apparently s o m e a n c i e n t v e r s i o n s o f L I L O i n v o k e d t h e k e r n e l w i t h % s s ! = % d s ,
# which h a p p e n e d t o w o r k b y a c c i d e n t f o r t h e o l d c o d e . R e c a l c u l a t e t h e s t a c k
# pointer i f % s s i s i n v a l i d . O t h e r w i s e l e a v e i t a l o n e , L O A D L I N s e t s u p t h e
# stack b e h i n d i t s o w n c o d e , s o w e c a n ' t b l i n d l y p u t i t d i r e c t l y p a s t t h e h e a p .
2007-10-26 03:11:33 +04:00
movw % s s , % d x
cmpw % a x , % d x # % d s = = % s s ?
movw % s p , % d x
2007-11-27 14:35:13 +03:00
je 2 f # - > a s s u m e % s p i s r e a s o n a b l y s e t
# Invalid % s s , m a k e u p a n e w s t a c k
movw $ _ e n d , % d x
testb $ C A N _ U S E _ H E A P , l o a d f l a g s
jz 1 f
movw h e a p _ e n d _ p t r , % d x
1 : addw $ S T A C K _ S I Z E , % d x
jnc 2 f
xorw % d x , % d x # P r e v e n t w r a p a r o u n d
2007-10-26 03:11:33 +04:00
2007-11-27 14:35:13 +03:00
2 : # Now % d x s h o u l d p o i n t t o t h e e n d o f o u r s t a c k s p a c e
2007-10-26 03:11:33 +04:00
andw $ ~ 3 , % d x # d w o r d a l i g n ( m i g h t a s w e l l . . . )
jnz 3 f
movw $ 0 x f f f c , % d x # M a k e s u r e w e ' r e n o t z e r o
2007-11-27 14:35:13 +03:00
3 : movw % a x , % s s
2007-10-26 03:11:33 +04:00
movzwl % d x , % e s p # C l e a r u p p e r h a l f o f % e s p
sti # N o w w e s h o u l d h a v e a w o r k i n g s t a c k
# We w i l l h a v e e n t e r e d w i t h % c s = % d s + 0 x20 , n o r m a l i z e % c s s o
# it i s o n p a r w i t h t h e o t h e r s e g m e n t s .
pushw % d s
pushw $ 6 f
lretw
6 :
2007-07-11 23:18:54 +04:00
# Check s i g n a t u r e a t e n d o f s e t u p
cmpl $ 0 x5 a5 a a a55 , s e t u p _ s i g
jne s e t u p _ b a d
# Zero t h e b s s
movw $ _ _ b s s _ s t a r t , % d i
movw $ _ e n d + 3 , % c x
xorl % e a x , % e a x
subw % d i , % c x
shrw $ 2 , % c x
rep; stosl
# Jump t o C c o d e ( s h o u l d n o t r e t u r n )
calll m a i n
# Setup c o r r u p t s o m e h o w . . .
setup_bad :
movl $ s e t u p _ c o r r u p t , % e a x
calll p u t s
# Fall t h r o u g h . . .
.globl die
.type die, @function
die :
hlt
jmp d i e
2007-09-11 01:39:02 +04:00
.size die, . - d i e
2007-07-11 23:18:54 +04:00
.section " .initdata " , " a"
setup_corrupt :
.byte 7
2007-07-27 03:10:22 +04:00
.string " No s e t u p s i g n a t u r e f o u n d . . . \ n "