On Sat, Mar 7, 2015 at 5:59 PM, David Rientjes 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
> memblock_x86_reserve_range_set
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 se
So we could let kexec-tools to rebuild SETUP_PCI and pass it to
second kernel if needed.
Now kexec-tools already build SETUP_EFI and SETUP_E820EXT.
Cc: Bjorn Helgaas
Cc: linux-...@vger.kernel.org
Signed-off-by: Yinghai Lu
---
arch/x86/pci/common.c | 175
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
Cc: David Vrabel
Signed-off-by: Yinghai Lu
-
Cc: Matt Fleming
Signed-off-by: Yinghai Lu
---
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 b/arch/x86/kernel/kdebugfs.c
index dc1404b..c8ca86c 1
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
Cc: linux-efi@vger.kernel.org
Signed-off-by: Yinghai Lu
---
arch/x86/include/asm/efi.h | 2 +-
arch/x86/platform/efi/efi.c| 13 ++
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
Cc: Matt Fleming
Cc: linux-...@vger.kernel.org
Signed-off-by: Yinghai Lu
---
arch/x86/include/asm/pci.h | 2 ++
arch/x86/kernel
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 SE
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
---
arch/x86/pci/common.c | 47 +
So we could avoid ioremap every time later.
Cc: Bjorn Helgaas
Cc: linux-...@vger.kernel.org
Signed-off-by: Yinghai Lu
---
arch/x86/include/asm/pci.h | 2 ++
arch/x86/kernel/setup.c| 1 +
arch/x86/pci/common.c | 77 +-
3 files changed, 65 in
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
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
Cc: linux-efi@vger.kernel.org
Signed-off-by: Yinghai Lu
---
arch/x86/include/asm/efi.h | 2 +-
arch/x86/platform/efi/efi.c| 13 ++
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 SE
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
First, aslr will support to put random VO above 4G, so we must set ident
mapping for the range even we come from startup_32 path.
Second, when boot from 64bit bootloader, bootloader set ident mapping,
and boot via ZO (arch/x86/boot/compressed/vmlinux) startup_64.
Those pages for pagetable need to
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
kaslr_
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
---
arch/x86/include/asm/page.h | 5 +++
arch/x86/mm/ident_map.c | 74
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 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 t
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 supportin
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 mem
On Sat, Mar 7, 2015 at 1:05 PM, Borislav Petkov 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 the
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 wa
On Fri, Mar 06, 2015 at 11:50:54AM -0800, Yinghai Lu wrote:
> On Fri, Mar 6, 2015 at 5:33 AM, Borislav Petkov 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 it
On Fri, Mar 06, 2015 at 09:49:25AM -0800, Yinghai Lu wrote:
> That is "copy and paste" instead of attachment for easy review.
> but gmail web client convert tab to spaces.
Next time you send a patch *only* for review *and* *not* for
application, do state that at the top like everyone else. Better
26 matches
Mail list logo