On 11/06/18 at 01:10pm, Borislav Petkov wrote:
> > I have another idea to solve this issue. Adding a SRAT parsing code
> > to arch/x86/mm/kaslr.c. It is useful for both EFI and BIOS and
> > also we don't need a new kernel parameter...
> > Dose the idea make sense?
>
> The more automatic stuff we d
On 10/22/18 at 06:13pm, Chao Fan wrote:
> >> +static bool process_mem_region(struct mem_vector *region,
> >> + unsigned long long minimum,
> >> + unsigned long long image_size)
> >> +{
> >> + int i;
> >> + /*
> >> + * If no immovable memory found,
On 10/22/18 at 03:30pm, Chao Fan wrote:
> On Mon, Oct 22, 2018 at 02:06:13PM +0800, Baoquan He wrote:
> >On 10/22/18 at 05:30am, Fan, Chao wrote:
> >> >> +static void get_acpi_rsdp(acpi_physical_address *rsdp_addr)
> >> >> +{
> >> >> +#ifd
On 10/22/18 at 05:29am, Fan, Chao wrote:
> On Sun, Oct 21, 2018 at 10:34:58AM +0800, Baoquan He wrote:
> >On 10/17/18 at 06:20pm, Chao Fan wrote:
> >> + if (!cmdline_find_option_bool("movable_node") ||
> >> + cmdline_find_option_arg(&quo
On 10/22/18 at 05:30am, Fan, Chao wrote:
> >> +static void get_acpi_rsdp(acpi_physical_address *rsdp_addr)
> >> +{
> >> +#ifdef CONFIG_KEXEC
> >> + unsigned long long res;
> >> + int len = 0;
> >> + char *val;
> >> +
> >> + val = malloc(20);
> >
> >Why is the length 20? Defined a macro?
> >
>
On 10/17/18 at 06:20pm, Chao Fan wrote:
> Dig out SRAT table from RSDP, and then walk all memory to find
> the immovable memory regions, and fill in the immovable_mem[].
> So that we can use it to select memory for KASLR.
>
> Signed-off-by: Chao Fan
> ---
> arch/x86/boot/compressed/Makefile |
On 10/17/18 at 06:20pm, Chao Fan wrote:
> If KEXEC write the RSDP pointer to cmdline, parse the cmdline
> and use it.
> Imitate from early_param of "acpi_rsdp".
>
> Signed-off-by: Chao Fan
> ---
> arch/x86/boot/compressed/acpitb.c | 23 +++
> 1 file changed, 23 insertions(+)
On 10/18/18 at 01:51pm, Chao Fan wrote:
> On Thu, Oct 18, 2018 at 12:03:38PM +0800, Baoquan He wrote:
> >On 10/17/18 at 06:20pm, Chao Fan wrote:
> >> Copy kstrtoull() to 'compressed' directory so that
> >> we can use it to change the address in cmdline f
On 10/18/18 at 01:54pm, Chao Fan wrote:
> On Thu, Oct 18, 2018 at 12:35:39PM +0800, Baoquan He wrote:
> >On 10/17/18 at 06:20pm, Chao Fan wrote:
> >> There is a bug that kaslr may randomly choose some positions
> >> which are located in movable memory regions. This wil
On 10/17/18 at 06:20pm, Chao Fan wrote:
> There is a bug that kaslr may randomly choose some positions
> which are located in movable memory regions. This will break memory
> hotplug feature and make the movable memory chosen by KASLR can't be
> removed. So dig SRAT table from ACPI tables to get me
On 10/17/18 at 06:20pm, Chao Fan wrote:
> If CONFIG_MEMORY_HOTREMOVE enabled, walk through the acpi srat memory
> tables and store those immovable memory regions so that kaslr can get
> where to choose for randomization.
This patch only adds invocation of get_immovable_mem() inside
mem_avoid_init(
On 10/17/18 at 06:20pm, Chao Fan wrote:
> If CONFIG_MEMORY_HOTREMOVE enabled and the amount of immovable
> memory regions is not zero. Calculate the intersection between memory
This if conditional adverbial clauses is not an complete sentence.
> regions from e820/efi memory table and immovable me
On 10/17/18 at 06:20pm, Chao Fan wrote:
> Copy kstrtoull() to 'compressed' directory so that
> we can use it to change the address in cmdline from
> string to unsigned long long.
So you don't like simple_strtoull() in arch/x86/boot/string.c which has
been used in boot/compressed/kaslr.c . Why? Are
On 10/17/18 at 06:20pm, Chao Fan wrote:
> +bool cmdline_find_option_arg(const char *option, const char *arg, int
> argsize)
> +{
> + char *buffer = malloc(argsize+1);
> + bool find = false;
> + int ret;
> +
> + ret = cmdline_find_option(option, buffer, argsize+1);
> + if (ret =
On 10/17/18 at 06:20pm, Chao Fan wrote:
> In the earliest time, I tried to dig ACPI tabls to solve this problem.
> But I didn't splite the code in 'compressed/' and ACPI code, so the patch
> is hard to follow so refused by community.
> Somebody suggest to add a kernel parameter to specify the
> imm
On 10/10/18 at 03:44pm, Masayoshi Mizuma wrote:
> On Wed, Oct 10, 2018 at 05:30:57PM +0800, Baoquan He wrote:
> > On 10/10/18 at 11:19am, Borislav Petkov wrote:
> > > On Wed, Oct 10, 2018 at 11:14:26AM +0200, Thomas Gleixner wrote:
> > > > Yes, it's differ
On 10/10/18 at 11:19am, Borislav Petkov wrote:
> On Wed, Oct 10, 2018 at 11:14:26AM +0200, Thomas Gleixner wrote:
> > Yes, it's different, but if the SRAT information is available early, then
> > the command line parameter can go away because then the required
> > information for Masa's problem is
On 10/10/18 at 05:12pm, Chao Fan wrote:
> On Wed, Oct 10, 2018 at 05:06:20PM +0800, Baoquan He wrote:
> >Hi Boris,
> >
> >On 10/10/18 at 10:59am, Borislav Petkov wrote:
> >> ... and we just picked up
> >>
> >> https://lkml.kernel.org/r/20181001140
Hi Boris,
On 10/10/18 at 10:59am, Borislav Petkov wrote:
> ... and we just picked up
>
> https://lkml.kernel.org/r/20181001140843.26137-1-msys.miz...@gmail.com
>
> and without having looked at the rest of your stuff, if people accept
> your solution, we don't need the silly parameter anymore, ri
Hi Chao,
On 08/07/18 at 02:49pm, Chao Fan wrote:
I think better add acpi/efi maintainers to CC when you post.
> +static acpi_physical_address get_rsdp_addr(void)
> +{
> + acpi_physical_address pa = 0;
> + bool status = false;
Here, I think you should make get_rsdp_addr() consistent wi
On 08/18/17 at 04:10pm, Ard Biesheuvel wrote:
> On 17 August 2017 at 14:04, Baoquan He wrote:
> > Thanks a lot for helping improving the patch log, Ingo! Will pay more
> > attention to the description in words and paragraph partition of log.
> >
> >>
> >
On 08/14/17 at 10:54pm, Baoquan He wrote:
> Currently KASLR will parse all e820 entries of RAM type and add all
> candidate position into slots array. Then we will choose one slot
> randomly as the new position which kernel will be decompressed into
> and run at.
>
> On syste
independent usage and struct efi_info for x86 arch only.
Introduce efi_early_memdesc_ptr to get pointer to a map descriptor, and
replace several places of open code with it.
Signed-off-by: Baoquan He
---
v9->v10:
Use the 'EFI subsystem' instead of EFI since EFI usually means
firm
On 08/16/17 at 12:37pm, Matt Fleming wrote:
> On Mon, 14 Aug, at 10:54:23PM, Baoquan He wrote:
> > The existing map iteration helper for_each_efi_memory_desc_in_map can
> > only be used after OS initializes EFI to fill data of struct efi_memory_map.
>
> Should this say
usage and struct efi_info for x86 arch only.
Introduce efi_early_memdesc_ptr to get pointer to a map descriptor, and
replace several places of open code with it.
Suggested-by: Ingo Molnar
Signed-off-by: Baoquan He
---
arch/x86/boot/compressed/eboot.c | 2 +-
drivers/firmware/efi
e820 memory map.
Signed-off-by: Baoquan He
---
arch/x86/boot/compressed/kaslr.c | 68 ++--
1 file changed, 66 insertions(+), 2 deletions(-)
diff --git a/arch/x86/boot/compressed/kaslr.c b/arch/x86/boot/compressed/kaslr.c
index 99c7194f7ea6..7de23bb279ce 1
sue fix according to Kees's comment.
This is based on tip/x86/boot, patch 1,2,3/4 in v5 post has
been put into tip/x86/boot now.
Baoquan He (2):
efi: Introduce efi_early_memdesc_ptr to get pointer to memmap
descriptor
x86/boot/KASLR: Restrict kernel to be randomized in mirror re
On 08/04/17 at 12:55pm, Matt Fleming wrote:
> On Fri, 04 Aug, at 07:40:05PM, Baoquan He wrote:
> > On 08/04/17 at 12:23pm, Matt Fleming wrote:
> > > On Fri, 28 Jul, at 07:26:03PM, Baoquan He wrote:
> > > > Hi Matt,
> > > >
> &g
On 08/04/17 at 12:23pm, Matt Fleming wrote:
> On Fri, 28 Jul, at 07:26:03PM, Baoquan He wrote:
> > Hi Matt,
> >
> > On 07/28/17 at 11:55am, Ingo Molnar wrote:
> > >
> > > * Matt Fleming wrote:
> > >
> > > > On Fri, 21 Jul, at 09:19:
On 08/04/17 at 05:59pm, Chao Fan wrote:
> On Fri, Aug 04, 2017 at 05:22:41PM +0800, Baoquan He wrote:
> >On 08/04/17 at 03:52pm, Baoquan He wrote:
> >> Sorry, NACK this series, there's error to hang system. Before I just
> >> halt system intentionally with error()
On 08/04/17 at 03:52pm, Baoquan He wrote:
> Sorry, NACK this series, there's error to hang system. Before I just
> halt system intentionally with error() to check the efi memmap printing,
> didn't notice this. Checking the cause.
I rebuilt the code or change the one of the rep
Sorry, NACK this series, there's error to hang system. Before I just
halt system intentionally with error() to check the efi memmap printing,
didn't notice this. Checking the cause.
On 08/04/17 at 03:26pm, Baoquan He wrote:
> Patch 1/2 is newly added to add efi_memdesc_ptr helpe
usage and struct efi_info for x86 ARCH only.
Introduce efi_memdesc_ptr to get pointer to a map descriptor, and replace
several places of open code with it.
Suggested-by: Ingo Molnar
Signed-off-by: Baoquan He
---
arch/x86/boot/compressed/eboot.c | 2 +-
drivers/firmware/efi
e820 memory map.
Signed-off-by: Baoquan He
---
arch/x86/boot/compressed/kaslr.c | 68 ++--
1 file changed, 66 insertions(+), 2 deletions(-)
diff --git a/arch/x86/boot/compressed/kaslr.c b/arch/x86/boot/compressed/kaslr.c
index 99c7194f7ea6..3d3ce762dc98 1
tyle issue fix according to Kees's comment.
This is based on tip/x86/boot, patch 1,2,3/4 in v5 post has
been put into tip/x86/boot now.
Baoquan He (2):
efi: Introduce efi_memdesc_ptr to get pointer to memmap descriptor
x86/boot/KASLR: Restrict kernel to be randomized in mirror regi
ay is not easy to understand, so I step back to take the pud entry copy
one by one method.
Hi Mike and Dave,
Could you also help review this patch?
If possible, it can still catch the latest version of RHEL GA.
Thanks
Baoquan
On 05/18/17 at 02:39pm, Baoquan He wrote:
> For EFI with
address X, pud_index(X) != pud_index(__va(X)). We can't only copy pgd entry
from direct mapping to build ident mapping, instead need copy pud entry
one by one from direct mapping.
Fix it.
Signed-off-by: Baoquan He
Signed-off-by: Dave Young
Cc: Matt Fleming
Cc: Ard Biesheuvel
Cc: Thomas Gle
On 05/17/17 at 11:35am, Baoquan He wrote:
> On 05/17/17 at 10:55am, Dave Young wrote:
> > Hi, Baoquan
> > > arch/x86/platform/efi/efi_64.c | 69
> > > +-
> > > 1 file changed, 61 insertions(+), 8 deletions(-)
> > &
On 05/17/17 at 10:55am, Dave Young wrote:
> Hi, Baoquan
> > arch/x86/platform/efi/efi_64.c | 69
> > +-
> > 1 file changed, 61 insertions(+), 8 deletions(-)
> >
> > diff --git a/arch/x86/platform/efi/efi_64.c b/arch/x86/platform/efi/efi_64.c
> > index c488
address X, pud_index(X) != pud_index(__va(X)). We can't only copy pgd entry
from direct mapping to build ident mapping, instead need copy pud entry
one by one from direct mapping.
Fix it.
Signed-off-by: Baoquan He
Signed-off-by: Dave Young
Cc: Matt Fleming
Cc: Ard Biesheuvel
Cc: Thomas Gle
511.020636] BMC r001i11b: Power OFF via BMC
[20170511.020701] BMC r001i11b: Power ON via BMC
>
> On Thu, 27 Apr, at 08:07:03PM, Baoquan He wrote:
> > For EFI with old_map enabled, Kernel will panic when kaslr is enabled.
> >
> > The root cause is the ident mapping i
On 05/08/17 at 05:25pm, Borislav Petkov wrote:
> On Mon, May 08, 2017 at 09:36:49AM +0800, Baoquan He wrote:
> > Thanks for explaining, Bhupesh.
> >
> > BIOS issue of SGI uv1 is still not fixed. There's a quirk for uv1 to
> > use efi old map:
> >
> &
On 05/08/17 at 05:25pm, Borislav Petkov wrote:
> On Mon, May 08, 2017 at 09:36:49AM +0800, Baoquan He wrote:
> > Thanks for explaining, Bhupesh.
> >
> > BIOS issue of SGI uv1 is still not fixed. There's a quirk for uv1 to
> > use efi old map:
> >
> &
Thanks for explaining, Bhupesh.
BIOS issue of SGI uv1 is still not fixed. There's a quirk for uv1 to
use efi old map:
void __init efi_apply_memmap_quirks(void)
{
...
...
/* UV2+ BIOS has a fix for this issue. UV1 still needs the quirk. */
if (dmi_check_system(sgi
34000] Kernel panic - not syncing: Attempted to kill the idle task!
[0.234000] ---[ end Kernel panic - not syncing: Attempted to kill the idle
task!
Signed-off-by: Baoquan He
Signed-off-by: Dave Young
Cc: Matt Fleming
Cc: Ard Biesheuvel
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc: "H. P
On 04/27/17 at 06:31pm, Baoquan He wrote:
> Hi Thomas,
>
> Thanks for reviewing!
>
> On 04/26/17 at 07:49am, Thomas Garnier wrote:
> > On Wed, Apr 26, 2017 at 3:43 AM, Baoquan He wrote:
> > > > arch/x86/platform/efi/efi_64.c | 35 +++---
Hi Thomas,
Thanks for reviewing!
On 04/26/17 at 07:49am, Thomas Garnier wrote:
> On Wed, Apr 26, 2017 at 3:43 AM, Baoquan He wrote:
> > > arch/x86/platform/efi/efi_64.c | 35 +++
> > > 1 file changed, 27 insertions(+), 8 deletions(-)
>
This bug will cause SGI uv 100 boot failure since SGI uv 100 can only
use efi old_map because of hardware. On rhel it failed all SGI uv series
since we haven't back ported fix for SGI uv 200/300.
On 04/26/17 at 06:39pm, Baoquan He wrote:
> For EFI with old_map enabled, Kernel will pa
34000] Kernel panic - not syncing: Attempted to kill the idle task!
[0.234000] ---[ end Kernel panic - not syncing: Attempted to kill the idle
task!
Signed-off-by: Baoquan He
Signed-off-by: Dave Young
Cc: Matt Fleming
Cc: Ard Biesheuvel
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc: "H. P
On 03/24/17 at 10:24am, Ingo Molnar wrote:
>
> * Dave Young wrote:
>
> > > > So I applied this kexec fix and extended the changelog to clearly show
> > > > why
> > > > this fix matters in practice.
> > >
> > > I thought it only impacts kexec, but Dave thought it will impact 1st
> > > kenrel
On 03/24/17 at 09:43am, Ard Biesheuvel wrote:
> On 24 March 2017 at 09:17, Baoquan He wrote:
> > EFI allocate runtime services regions from EFI_VA_START, -4G, down
> > to -68G, EFI_VA_END, 64G altogether. The mechanism was introduced in
> > commit d2f7cbe7b26a7 ("x86/efi
EFI allocate runtime services regions from EFI_VA_START, -4G, down
to -68G, EFI_VA_END, 64G altogether. The mechanism was introduced in
commit d2f7cbe7b26a7 ("x86/efi: Runtime services virtual mapping").
Clean it up to avoid confusion.
Signed-off-by: Baoquan He
---
v1->v2:
Update
On 03/24/17 at 08:57am, Ard Biesheuvel wrote:
> On 23 March 2017 at 03:27, Baoquan He wrote:
> > EFI allocate runtime services regions from EFI_VA_START, -4G, down
> > to -64G, EFI_VA_END.
>
> OK, so is the size of the region 60 GB or 64 GB? This suggests 60 GB,
> bu
On 03/24/17 at 09:08am, Ingo Molnar wrote:
> > Cc: #4.8+
> > Signed-off-by: Baoquan He
> > Acked-by: Dave Young
> > Reviewed-by: Bhupesh Sharma
> > Acked-by: Thomas Garnier
> > Cc: Thomas Gleixner
> > Cc: Ingo Molnar
> > Cc: "H. Pe
G, and EFI_VA_END = -64G.
Changing EFI_VA_START to EFI_VA_END in mm/kaslr.c fixes this problem.
Cc: #4.8+
Signed-off-by: Baoquan He
Acked-by: Dave Young
Reviewed-by: Bhupesh Sharma
Acked-by: Thomas Garnier
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc: "H. Peter Anvin"
Cc: x...@kernel.o
EFI allocate runtime services regions from EFI_VA_START, -4G, down
to -64G, EFI_VA_END. The mechanism was introduced in
commit d2f7cbe7b26a7 ("x86/efi: Runtime services virtual mapping").
Clean it up to avoid confusion.
Signed-off-by: Baoquan He
Cc: Matt Fleming
Cc: Ard Biesheuvel
On 03/15/17 at 02:13pm, Baoquan He wrote:
> PING!
>
> Is there any suggestion for this code bug fix?
>
> Boris added comment in patch 1/2 thread that it can also be fixed by
> swapping the naming - EFI_VA_START and EFI_VA_END. As he said the
> swapping can remove the confu
people who have the current
mental picture of the mapping direction.
And there's also a well known similar use case, stack, like stack_end
naming in arch/x86/boot/main.c which is the low addr boundary of stack
region.
Any idea?
Thanks
Baoquan
On 03/08/17 at 03:47pm, Baoquan He wrote:
> EFI a
EFI allocates runtime services regions starting from EFI_VA_START, -4G,
decrement to EFI_VA_END. So remove the bottom-up term to avoid confusion.
Signed-off-by: Baoquan He
---
arch/x86/platform/efi/efi_64.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/arch/x86
On 03/08/17 at 10:35am, Borislav Petkov wrote:
> On Wed, Mar 08, 2017 at 05:09:55PM +0800, Baoquan He wrote:
> > Yes, it looks better. I can repost with this change. Thanks.
>
> No it doesn't:
All right, I will just update the code comment. Just back ported kaslr
to ou
On 03/08/17 at 02:30pm, Bhupesh Sharma wrote:
> Hi Dave,
>
> On Wed, Mar 8, 2017 at 1:48 PM, Dave Young wrote:
> > On 03/08/17 at 03:47pm, Baoquan He wrote:
> >> - * We allocate runtime services regions bottom-up, starting from -4G, i.e.
> >> + * We allocate
On 03/08/17 at 02:30pm, Bhupesh Sharma wrote:
> Hi Dave,
>
> On Wed, Mar 8, 2017 at 1:48 PM, Dave Young wrote:
> > On 03/08/17 at 03:47pm, Baoquan He wrote:
> >> EFI allocate runtime services regions down from EFI_VA_START, -4G.
> >> It should be top-down
On 03/08/17 at 09:54am, Borislav Petkov wrote:
> On Wed, Mar 08, 2017 at 04:45:13PM +0800, Baoquan He wrote:
> > -4G and -68G just a trick which makes people understand easily, still we
> > think kernel text mapping region is in higher addr area then vmalloc. I
> > personn
Forgot cc to Boris, add him.
On 03/08/17 at 04:18pm, Dave Young wrote:
> On 03/08/17 at 03:47pm, Baoquan He wrote:
> > EFI allocate runtime services regions down from EFI_VA_START, -4G.
> > It should be top-down handling.
> >
> > Signed-off-by: Baoquan He
> &g
START.
Correct it in this patch.
Signed-off-by: Baoquan He
---
arch/x86/mm/kaslr.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/x86/mm/kaslr.c b/arch/x86/mm/kaslr.c
index 887e571..aed2064 100644
--- a/arch/x86/mm/kaslr.c
+++ b/arch/x86/mm/kaslr.c
@@ -48,7 +48,7 @@ s
EFI allocate runtime services regions down from EFI_VA_START, -4G.
It should be top-down handling.
Signed-off-by: Baoquan He
---
arch/x86/platform/efi/efi_64.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/x86/platform/efi/efi_64.c b/arch/x86/platform/efi/efi_64.c
mem_avoid handling simple.
>
> Also put 7 patches from He that support random random, as I already used
> his patches to test the ident mapping code, and could save some rebase
> work for him.
>
> also at:
> git://git.kernel.org/pub/scm/linux/kernel/git/yinghai/linux-yinghai
On 03/18/15 at 12:28am, Yinghai Lu wrote:
> While looking at the boot code to add mem mapping for kasl
> with 64bit above 4G support, I found that e6023367d779 ("x86, kaslr: Prevent
> .bss from overlaping initrd") and later introduced way to get kernel run_size
> and pass it around. First via perl
68 matches
Mail list logo
