On Sat, Mar 7, 2015 at 5:59 PM, David Rientjes rient...@google.com wrote:
Hmm, although the bug is reported for a 3.12 kernel, I assume this is for
stable 3.10+? If so, it should apply fine with the exception of removing
e820_reserve_setup_data() from setup_arch() rather than
Now ZO sit end of the buffer, we can find out where is ZO text
and data/bss etc.
[input, input+input_size) is copied compressed kernel, not the whole ZO.
[output, output+init_size) is the buffer for VO.
[input+input_size, output+init_size) is [_text, _end) for ZO.
that could be first range in
First 3 patches make ZO (arch/x86/boot/compressed/vmlinux) data region is not
overwritten by VO (vmlinux) after decompress. So could pass data from ZO to VO.
The 4th one is fixing kaslr_enabled accessing. Old code is using address
as value wrongly.
Last 3 patches are the base for kaslr
On Sat, Mar 7, 2015 at 1:05 PM, Borislav Petkov b...@suse.de wrote:
On Fri, Mar 06, 2015 at 11:53:22AM -0800, Yinghai Lu wrote:
---
Commit
f47233c2d34f (x86/mm/ASLR: Propagate base load address calculation)
started passing KASLR status to kernel proper, but it uses a physical
address as
Now we are using memblock to do early resource reserver/allocation
instead of using e820 map directly, and setup_data is reserved in
memblock early already.
Also kexec generate setup_data and pass pointer to second kernel,
so second kernel reserve setup_data by their own.
(Now kexec-tools create
commit e6023367d779 (x86, kaslr: Prevent .bss from overlaping initrd)
introduced one run_size for kaslr.
We should use real runtime size (include copy/decompress) aka init_size.
run_size is VO (vmlinux) init size include bss and brk.
init_size is the size needed for decompress and it is bigger
On Fri, Mar 06, 2015 at 11:53:22AM -0800, Yinghai Lu wrote:
That will get wrong value back for kaslr_enabled in kernel stage.
1. When kaslr is not enabled at boot/choose_kernel_location, if kaslr_enabled
get set wrongly in setup.c, late in module.c::get_module_load_offset
will return not
On Fri, Mar 06, 2015 at 11:50:54AM -0800, Yinghai Lu wrote:
On Fri, Mar 6, 2015 at 5:33 AM, Borislav Petkov b...@suse.de wrote:
However, the setup_data linked list and thus the element which contains
kaslr_enabled is chained together using physical addresses. At the
time when we access
Boris found data from boot stage can not be used kernel stage.
Bootloader allocate buffer according to init_size in hdr, and load the
ZO (arch/x86/boot/compressed/vmlinux) from start of that buffer.
During running of ZO, ZO move itself to the middle of buffer at
z_extract_offset to make sure that
We need to include that in boot::decompress_kernel stage to set new
ident mapping.
Also add checking for __pa/__va macro definition, as we need to override them
in boot::decompress_kernel stage.
Signed-off-by: Yinghai Lu ying...@kernel.org
---
arch/x86/include/asm/page.h | 5 +++
Boris found data from boot stage can not be used kernel stage.
Bootloader allocate buffer according to init_size in hdr, and load the
ZO (arch/x86/boot/compressed/vmlinux) from start of that buffer.
During running of ZO, ZO move itself to the middle of buffer at
z_extract_offset to make sure that
Commit
f47233c2d34f (x86/mm/ASLR: Propagate base load address calculation)
started passing KASLR status to kernel proper, but it uses a physical
address as the vaule, leading to parsing bogus KASLR status in kernel
proper.
The setup_data linked list and thus the element which contains
So we could avoid ioremap every time later.
Cc: Bjorn Helgaas bhelg...@google.com
Cc: linux-...@vger.kernel.org
Signed-off-by: Yinghai Lu ying...@kernel.org
---
arch/x86/include/asm/pci.h | 2 ++
arch/x86/kernel/setup.c| 1 +
arch/x86/pci/common.c | 77
Now setup_data is reserved via memblock and e820 and different
handlers have different ways, and it is confusing.
1. SETUP_E820_EXT: is consumed early and will not copy or access again.
have memory wasted.
2. SETUP_EFI: is accessed via ioremap every time at early stage.
have memory
On Sat, 7 Mar 2015, Yinghai Lu wrote:
Now we are using memblock to do early resource reserver/allocation
instead of using e820 map directly, and setup_data is reserved in
memblock early already.
Also kexec generate setup_data and pass pointer to second kernel,
so second kernel reserve
We will not reserve setup_data in generic code. Every handler need to
reserve and copy setup_data locally.
Current dtd handling already have code for copying, just add reserve code.
Also simplify code a bit by storing real dtb size.
Cc: Rob Herring r...@kernel.org
Cc: David Vrabel
Cc: Matt Fleming matt.flem...@intel.com
Signed-off-by: Yinghai Lu ying...@kernel.org
---
arch/x86/kernel/kdebugfs.c | 142 -
arch/x86/kernel/setup.c| 17 --
2 files changed, 159 deletions(-)
diff --git a/arch/x86/kernel/kdebugfs.c
The copy will be in __initdata, and it is small.
We can use pointer to access the setup_data instead of using early_memmap
everywhere.
Cc: Matt Fleming matt.flem...@intel.com
Cc: linux-efi@vger.kernel.org
Signed-off-by: Yinghai Lu ying...@kernel.org
---
arch/x86/include/asm/efi.h | 2 +-
Let it reserve setup_data, and keep it's own list.
Also clear the hdr.setup_data, as all handler now handle or
reserve setup_data locally already.
Cc: Bjorn Helgaas bhelg...@google.com
Cc: Matt Fleming matt.flem...@intel.com
Cc: linux-...@vger.kernel.org
Signed-off-by: Yinghai Lu
Now we are using memblock to do early resource reserver/allocation
instead of using e820 map directly, and setup_data is reserved in
memblock early already.
Also kexec generate setup_data and pass pointer to second kernel,
so second kernel reserve setup_data by their own.
(Now kexec-tools create
As EFI stub code could put them high when on 32bit or with exactmap=
on 64bit conf.
Check if the range is mapped, otherwise allocate new one and have
the rom data copied. So we could access them directly.
Signed-off-by: Yinghai Lu ying...@kernel.org
---
arch/x86/pci/common.c | 47
21 matches
Mail list logo
