Re: [PATCH 1/5] x86_64: fix kasan shadow region page tables

Ingo Molnar
2015-07-02T07:57:07Z

* Andrey Ryabinin <a.ryabinin@samsung.com> wrote:

> On 07/01/2015 12:07 PM, Ingo Molnar wrote:
> >
> > * Andrey Ryabinin <a.ryabinin@samsung.com> wrote:
> >
> >> diff --git a/arch/x86/kernel/head64.c b/arch/x86/kernel/head64.c
> >> index 5a46681..f129a9a 100644
> >> --- a/arch/x86/kernel/head64.c
> >> +++ b/arch/x86/kernel/head64.c
> >> @@ -161,11 +161,12 @@ asmlinkage __visible void __init x86_64_start_kernel(char * real_mode_data)
> >> /* Kill off the identity-map trampoline */
> >> reset_early_page_tables();
> >>
> >> - kasan_map_early_shadow(early_level4_pgt);
> >> -
> >> - /* clear bss before set_intr_gate with early_idt_handler */
> >> clear_bss();
> >>
> >> + clear_page(init_level4_pgt);
> >> +
> >> + kasan_early_init();
> >> +
> >> for (i = 0; i < NUM_EXCEPTION_VECTORS; i++)
> >> set_intr_gate(i, early_idt_handler_array[i]);
> >> load_idt((const struct desc_ptr *)&idt_descr);
> >> @@ -177,12 +178,9 @@ asmlinkage __visible void __init x86_64_start_kernel(char * real_mode_data)
> >> */
> >> load_ucode_bsp();
> >>
> >> - clear_page(init_level4_pgt);
> >> /* set init_level4_pgt kernel high mapping*/
> >> init_level4_pgt[511] = early_level4_pgt[511];
> >>
> >> - kasan_map_early_shadow(init_level4_pgt);
> >> -
> >> x86_64_start_reservations(real_mode_data);
> >> }
> >>
> >
> > So this changes generic code (moves the clear_page(init_level4_pgt) call), but the
> > changelog claims it's a KASAN-specific change.
> >
> > Please split this into two patches: the first one does the generic change, the
> > second one the KASAN specific one.
> >
>
> Hm... We will need to backport that generic change to stable, because second change depends on it.
> So, maybe split this on three changes:
>
> #1 fix kasan page tables (without touching clear_page() or kasan_map_early_shadow(init_level4_pgt))
> #2 generic move clear_page()
> #3 clean up kasan initialization (move kasan_map_early_shadow(init_level4_pgt)).
>
> Only #1 will have stable tag. Does that makes sense?

I wouldn't overcomplicate it - just split it up and both patches can get the
stable tag just fine...

Thanks,

Ingo