[PATCH] arm64:mm Remove the redundant initrd memblock codes
Dennis Chen
dennis.chen at arm.com
Wed Jul 6 03:07:27 PDT 2016
On Wed, Jul 06, 2016 at 10:47:57AM +0200, Ard Biesheuvel wrote:
> On 5 July 2016 at 06:18, Dennis Chen <dennis.chen at arm.com> wrote:
> > On Tue, Jul 05, 2016 at 11:41:02AM +0800, Ard Biesheuvel wrote:
> >>
> >> > On 5 jul. 2016, at 10:22, Dennis Chen <dennis.chen at arm.com> wrote:
> >> >
> >> >> On Mon, Jul 04, 2016 at 12:33:05PM +0200, Ard Biesheuvel wrote:
> >> >>
> >> >>> On 4 jul. 2016, at 06:53, Dennis Chen <dennis.chen at arm.com> wrote:
> >> >>>
> >> >>> The memory range between initrd_start and initrd_end was added to the memblock
> >> >>> twice unnecessarily in the same function before initrd memory range can be freed.
> >> >>> This patch merge those codes into one piece of block and add the initrd memory
> >> >>> range only once, also it makes the code clean and simple.
> >> >>
> >> >> This is likely to break under KASLR (and I would recommend that you test with kaslr enabled when you propose changes to this code)
> >> > Hello Ard, I've tested it under KASLR on Juno board before proposing the changes,where the firmware provides the RNG protocol, it works well.
> >>
> >> Ok, thanks for confirming that (and apologies for assuming you did not test it)
> >>
> >> >>
> >> >> The randomization of memstart_addr needs to execute /after/ adding back the initrd, otherwise the chosen value of memstart_addr may push the initrd beyond the end of the linear area into the userland range.
> >> > Yes, I know the 'range' is depends on memblock_end_of_DRAM() and memblock_start_of_DRAM(), but I can't see that the order of initrd added to the memblock will affect
> >> > those two values returned from memblock_ fucntions, IMHO the initrd will be loaded to somewhere within the DRAM by firmware, is that correct?
> >>
> >> memblock_add/_remove may affect the return values of memblock_start/_end_of_DRAM, so the reordering will affect the range of the randomized memstart_addr, afaict
> >>
> > Hello Ard, since the efi stub will load the initrd block to the DRAM, and all the memory descriptions passed in by the firmware will be added to the memblock by efi
> > stub, so in this case adding the initrd to the memblock will not change the return value of memblock_start/_end_of_DRAM, else it's a bug from efi stub, isn't it?
> >
>
> First of all, every memblock_add/_remove call is likely to affect
> either memblock_start_of_DRAM or memblock_end_of_DRAM. The EFI stub
> does not manipulate the memblock table, it simply retrieves the UEFI
> memory map from the firmware and hands the address to the kernel
> proper.
>
> But more importantly, the initrd could be loaded not only by the EFI
> stub, but also by GRUB, and so we should be able to gracefully handle
> the case where the initrd ends up in a place where it is outside of
> the linear mapping, either due to a mem= kernel command line argument,
> or due to an insufficient VA size (e.g., the Freescale platform that
> puts 2 GB at 0x8000_0000 and the remaining memory at 0x80_0000_0000
> cannot run an ordinary 39-bit VA kernel without losing access to a
> substantial chunk of its memory)
>
Hello Ard, Freescale platform is a good example. In this case, with 39-bit
VA, the linear map area is only 256GB, while the upper memory block on that
platform is 0x80_0000_0000 exceeding the linear size, so current code will not
put the [0x80_0000_0000, size] into the memblock, if kernel is loaded into the
lower address memblock [0x8000_0000, size] while initrd block is loaded into
the higher memblock, so the memblock_end_of_DRAM() will be changed after adding
back the initrd.
OK, so please modulo my prior comments/questions. Maybe we can have:
-------->8--------
diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
index 2ade7a6..2dede3b 100644
--- a/arch/arm64/mm/init.c
+++ b/arch/arm64/mm/init.c
@@ -279,15 +279,11 @@ void __init arm64_memblock_init(void)
* pagetables with memblock.
*/
memblock_reserve(__pa(_text), _end - _text);
-#ifdef CONFIG_BLK_DEV_INITRD
- if (initrd_start) {
- memblock_reserve(initrd_start, initrd_end - initrd_start);
-
+ if (IS_ENABLED(CONFIG_BLK_DEV_INITRD) && initrd_start) {
/* the generic initrd code expects virtual addresses */
initrd_start = __phys_to_virt(initrd_start);
initrd_end = __phys_to_virt(initrd_end);
}
-#endif
-------->8--------
But I really have no keen on this kind of cleanup. So let's ignore this changes,
and thanks for the clarification!
Thanks,
Dennis
>
> So this means that we cannot randomize the linear mapping until we
> have added [back] the pieces we expect to be covered by it, which are
> the [_text, _end) kernel range, and the initrd.
>
>
>
> >> >>> Signed-off-by: Dennis Chen <dennis.chen at arm.com>
> >> >>> Cc: Mark Rutland <mark.rutland at arm.com>
> >> >>> Cc: Steve Capper <steve.capper at arm.com>
> >> >>> Cc: Catalin Marinas <catalin.marinas at arm.com>
> >> >>> Cc: Ard Biesheuvel <ard.biesheuvel at linaro.org>
> >> >>> Cc: Will Deacon <will.deacon at arm.com>
> >> >>> ---
> >> >>> arch/arm64/mm/init.c | 58 +++++++++++++++++++++++-----------------------------
> >> >>> 1 file changed, 26 insertions(+), 32 deletions(-)
> >> >>>
> >> >>> diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
> >> >>> index 2ade7a6..cf26cdb 100644
> >> >>> --- a/arch/arm64/mm/init.c
> >> >>> +++ b/arch/arm64/mm/init.c
> >> >>> @@ -228,6 +228,29 @@ void __init arm64_memblock_init(void)
> >> >>> memblock_add(__pa(_text), (u64)(_end - _text));
> >> >>> }
> >> >>>
> >> >>> + if (IS_ENABLED(CONFIG_RANDOMIZE_BASE)) {
> >> >>> + extern u16 memstart_offset_seed;
> >> >>> + u64 range = linear_region_size -
> >> >>> + (memblock_end_of_DRAM() - memblock_start_of_DRAM());
> >> >>> +
> >> >>> + /*
> >> >>> + * If the size of the linear region exceeds, by a sufficient
> >> >>> + * margin, the size of the region that the available physical
> >> >>> + * memory spans, randomize the linear region as well.
> >> >>> + */
> >> >>> + if (memstart_offset_seed > 0 && range >= ARM64_MEMSTART_ALIGN) {
> >> >>> + range = range / ARM64_MEMSTART_ALIGN + 1;
> >> >>> + memstart_addr -= ARM64_MEMSTART_ALIGN *
> >> >>> + ((range * memstart_offset_seed) >> 16);
> >> >>> + }
> >> >>> + }
> >> >>> +
> >> >>> + /*
> >> >>> + * Register the kernel text, kernel data, initrd, and initial
> >> >>> + * pagetables with memblock.
> >> >>> + */
> >> >>> + memblock_reserve(__pa(_text), _end - _text);
> >> >>> +
> >> >>> if (IS_ENABLED(CONFIG_BLK_DEV_INITRD) && initrd_start) {
> >> >>> /*
> >> >>> * Add back the memory we just removed if it results in the
> >> >>> @@ -254,41 +277,12 @@ void __init arm64_memblock_init(void)
> >> >>> memblock_remove(base, size); /* clear MEMBLOCK_ flags */
> >> >>> memblock_add(base, size);
> >> >>> memblock_reserve(base, size);
> >> >>> + /* the generic initrd code expects virtual addresses */
> >> >>> + initrd_start = __phys_to_virt(initrd_start);
> >> >>> + initrd_end = __phys_to_virt(initrd_end);
> >> >>> }
> >> >>> }
> >> >>>
> >> >>> - if (IS_ENABLED(CONFIG_RANDOMIZE_BASE)) {
> >> >>> - extern u16 memstart_offset_seed;
> >> >>> - u64 range = linear_region_size -
> >> >>> - (memblock_end_of_DRAM() - memblock_start_of_DRAM());
> >> >>> -
> >> >>> - /*
> >> >>> - * If the size of the linear region exceeds, by a sufficient
> >> >>> - * margin, the size of the region that the available physical
> >> >>> - * memory spans, randomize the linear region as well.
> >> >>> - */
> >> >>> - if (memstart_offset_seed > 0 && range >= ARM64_MEMSTART_ALIGN) {
> >> >>> - range = range / ARM64_MEMSTART_ALIGN + 1;
> >> >>> - memstart_addr -= ARM64_MEMSTART_ALIGN *
> >> >>> - ((range * memstart_offset_seed) >> 16);
> >> >>> - }
> >> >>> - }
> >> >>> -
> >> >>> - /*
> >> >>> - * Register the kernel text, kernel data, initrd, and initial
> >> >>> - * pagetables with memblock.
> >> >>> - */
> >> >>> - memblock_reserve(__pa(_text), _end - _text);
> >> >>> -#ifdef CONFIG_BLK_DEV_INITRD
> >> >>> - if (initrd_start) {
> >> >>> - memblock_reserve(initrd_start, initrd_end - initrd_start);
> >> >>> -
> >> >>> - /* the generic initrd code expects virtual addresses */
> >> >>> - initrd_start = __phys_to_virt(initrd_start);
> >> >>> - initrd_end = __phys_to_virt(initrd_end);
> >> >>> - }
> >> >>> -#endif
> >> >>> -
> >> >>> early_init_fdt_scan_reserved_mem();
> >> >>>
> >> >>> /* 4GB maximum for 32-bit only capable devices */
> >> >>> --
> >> >>> 1.8.3.1
> >> >
> >>
> >
>
More information about the linux-arm-kernel
mailing list