[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20160413100507.GB9482@gmail.com>
Date: Wed, 13 Apr 2016 12:05:07 +0200
From: Ingo Molnar <mingo@...nel.org>
To: Baoquan He <bhe@...hat.com>
Cc: linux-kernel@...r.kernel.org, yinghai@...nel.org,
keescook@...omium.org, hpa@...or.com, mingo@...hat.com,
bp@...en8.de, vgoyal@...hat.com, luto@...nel.org,
lasse.collin@...aani.org, akpm@...ux-foundation.org,
dyoung@...hat.com, Jiri Kosina <jkosina@...e.cz>,
Borislav Petkov <bp@...e.de>
Subject: Re: [PATCH v4 11/20] x86, 64bit: Set ident_mapping for kaslr
* Baoquan He <bhe@...hat.com> wrote:
> From: Yinghai Lu <yinghai@...nel.org>
>
> Current aslr only support random in small range, from 16M to 1G. And
> new range still use old mapping. Also it does not support new range
> above 4G.
>
> We need to have ident mapping for the new range before we can do
> decompress to the new output, and later run them.
>
> In this patch, we add ident mapping for all needed range.
>
> At first, to support aslr to put random VO above 4G, we must set ident
> mapping for the new range when it come via startup_32 path.
>
> Secondly, 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 be avoided when we select new random
> VO (vmlinux) base. Otherwise decompressor would overwrite them during
> decompressing.
> First way would be: walk through pagetable and find out every page is used
> by pagetable for every mem_aovid checking but we will need extra code, and
> may need to increase mem_avoid array size to hold them.
> Other way would be: We can create new ident mapping instead, and pages for
> pagetable will come from _pagetable section of ZO, and they are in
> mem_avoid array already. In this way, we can reuse the code for ident
> mapping.
>
> The _pgtable will be shared by 32bit and 64bit path to reduce init_size,
> as now ZO _rodata to _end will contribute init_size.
>
> We need to increase pgt buffer size.
> When boot via startup_64, as we need to cover old VO, params, cmdline
> and new VO, in extreme case we could have them all cross 512G boundary,
> will need (2+2)*4 pages with 2M mapping. And need 2 for first 2M for vga
> ram. Plus one for level4. Total will be 19 pages.
> When boot via startup_32, aslr would move new VO above 4G, we need set
> extra ident mapping for new VO, pgt buffer come from _pgtable offset 6
> pages. Should only need (2+2) pages at most when it cross 512G boundary.
> So 19 pages could make both paths happy.
Guys, when you pick up patches and if you add Reviewed-by tags, don't just pass
through crap but _fix_ the changelogs!
The very first sentence:
> Current aslr only support random in small range, from 16M to 1G. And
and it gets worse from there on.
Also, please capitalize consistently, spell KASLR, not 'kaslr' or 'aslr'.
Thanks,
Ingo
Powered by blists - more mailing lists