linux-kernel - RE: [EXT] Re: [PATCH] of/fdt: move elfcorehdr reservation early for crash dump kernel

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <PAXPR04MB83348BB9265516255BBB2ACB8B269@PAXPR04MB8334.eurprd04.prod.outlook.com>
Date:   Tue, 1 Feb 2022 15:36:59 +0000
From:   Nikhil Gupta <nikhil.gupta@....com>
To:     Rob Herring <robh+dt@...nel.org>
CC:     linux-arm-kernel <linux-arm-kernel@...ts.infradead.org>,
        Frank Rowand <frowand.list@...il.com>,
        "devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        Priyanka Jain <priyanka.jain@....com>,
        Aisheng Dong <aisheng.dong@....com>
Subject: RE: [EXT] Re: [PATCH] of/fdt: move elfcorehdr reservation early for
 crash dump kernel

Hello Rob,

This issue will come in scenarios where the memory has been reserved using fdt_init_reserved_mem()
The memory address which is reserved overlaps with the address of elfcorehdr which has a fixed address,
So the memory for elfcorehdr needs to be reserved first.

crashkernel memory range : 0x00000000d4000000 - 0x00000000f4000000 (512 MB)
elfcorehdr addr is calculated in kexec tool based on reserved crashkernel memory space. (Last page is used in top down order)
elfcorehdr conflict with memory [    0.000000] memblock_reserve: [0x00000000f3c00000-0x00000000f3ffffff] reserved by fdt_init_reserved_mem()

Without Patch:

[    0.000000] memblock_reserve: [0x00000000d4010000-0x00000000d677ffff] arm64_memblock_init+0x258/0x2c8
[    0.000000] memblock_phys_alloc_range: 4194304 bytes align=0x400000 from=0x0000000000000000 max_addr=0x0001000000000000 early_init_dt_alloc_reserved_memory_arch+0x9c/0x16c
[    0.000000] memblock_reserve: [0x00000000f3c00000-0x00000000f3ffffff] memblock_alloc_range_nid+0xdc/0x150
[    0.000000] memblock_phys_alloc_range: 33554432 bytes align=0x2000000 from=0x0000000000000000 max_addr=0x0001000000000000 early_init_dt_alloc_reserved_memory_arch+0x9c/0x16c
[    0.000000] memblock_reserve: [0x00000000f0000000-0x00000000f1ffffff] memblock_alloc_range_nid+0xdc/0x150
[    0.000000] memblock_phys_alloc_range: 16777216 bytes align=0x1000000 from=0x0000000000000000 max_addr=0x0001000000000000 early_init_dt_alloc_reserved_memory_arch+0x9c/0x16c
[    0.000000] memblock_reserve: [0x00000000f2000000-0x00000000f2ffffff] memblock_alloc_range_nid+0xdc/0x150
[    0.000000] OF: reserved mem: initialized node bman-fbpr, compatible id fsl,bman-fbpr
[    0.000000] OF: fdt: elfcorehdr is overlapped

With Patch:

[    0.000000] memblock_remove: [0x0001000000000000-0x0000fffffffffffe] arm64_memblock_init+0xa0/0x2d8
[    0.000000] memblock_remove: [0x00008000c0000000-0x00008000bffffffe] arm64_memblock_init+0xfc/0x2d8
[    0.000000] memblock_remove: [0x00000000d6160000-0x00000000d83befff] arm64_memblock_init+0x1c8/0x2d8
[    0.000000] memblock_add: [0x00000000d6160000-0x00000000d83befff] arm64_memblock_init+0x1d4/0x2d8
[    0.000000] memblock_reserve: [0x00000000d6160000-0x00000000d83befff] arm64_memblock_init+0x1e0/0x2d8
[    0.000000] memblock_reserve: [0x00000000d4010000-0x00000000d615ffff] arm64_memblock_init+0x260/0x2d8
[    0.000000] memblock_reserve: [0x00000000f3fff000-0x00000000f3fff3ff] early_init_fdt_scan_reserved_mem+0x370/0x3c8
[    0.000000] OF: fdt: Reserving 1 KiB of memory at 0xf3fff000 for elfcorehdr
[    0.000000] memblock_phys_alloc_range: 4194304 bytes align=0x400000 from=0x0000000000000000 max_addr=0x0001000000000000 early_init_dt_alloc_reserved_memory_arch+0x38/0x8c
[    0.000000] memblock_reserve: [0x00000000f3800000-0x00000000f3bfffff] memblock_alloc_range_nid+0xdc/0x150
[    0.000000] memblock_phys_alloc_range: 33554432 bytes align=0x2000000 from=0x0000000000000000 max_addr=0x0001000000000000 early_init_dt_alloc_reserved_memory_arch+0x38/0x8c
[    0.000000] memblock_reserve: [0x00000000f0000000-0x00000000f1ffffff] memblock_alloc_range_nid+0xdc/0x150
[    0.000000] memblock_phys_alloc_range: 16777216 bytes align=0x1000000 from=0x0000000000000000 max_addr=0x0001000000000000 early_init_dt_alloc_reserved_memory_arch+0x38/0x8c

Kind Regards,
Nikhil

-----Original Message-----
From: Rob Herring <robh+dt@...nel.org> 
Sent: Friday, January 28, 2022 9:03 PM
To: Nikhil Gupta <nikhil.gupta@....com>
Cc: linux-arm-kernel <linux-arm-kernel@...ts.infradead.org>; Frank Rowand <frowand.list@...il.com>; devicetree@...r.kernel.org; linux-kernel@...r.kernel.org; Priyanka Jain <priyanka.jain@....com>; Aisheng Dong <aisheng.dong@....com>
Subject: [EXT] Re: [PATCH] of/fdt: move elfcorehdr reservation early for crash dump kernel

Caution: EXT Email

On Thu, Jan 27, 2022 at 10:23 PM <nikhil.gupta@....com> wrote:
>
> From: Nikhil Gupta <nikhil.gupta@....com>
>
> elfcorehdr_addr is fixed address passed to Second kernel which may be 
> conflicted with potential reserved memory in Second kernel,so 
> fdt_reserve_elfcorehdr() ahead of fdt_init_reserved_mem() can relieve this situation.

How does changing the order help exactly? If you have an overlap, that seems bad no matter what. What if the overlapping reserved area is used by another core or firmware?

Rob