linux-kernel - Re: [PATCH v2 3/3] riscv/kexec: load initrd high in available memory

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]

Date:   Wed, 26 Jul 2023 20:27:34 +0200
From:   Petr Tesarik <petrtesarik@...weicloud.com>
To:     Conor Dooley <conor@...nel.org>
Cc:     Paul Walmsley <paul.walmsley@...ive.com>,
        Palmer Dabbelt <palmer@...belt.com>,
        Albert Ou <aou@...s.berkeley.edu>,
        Conor Dooley <conor.dooley@...rochip.com>,
        Li Huafei <lihuafei1@...wei.com>,
        Liao Chang <liaochang1@...wei.com>,
        Masahiro Yamada <masahiroy@...nel.org>,
        Kees Cook <keescook@...omium.org>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Heiko Stuebner <heiko@...ech.de>,
        Ricardo Ribalda <ribalda@...omium.org>,
        Alyssa Ross <hi@...ssa.is>, Li Zhengyu <lizhengyu3@...wei.com>,
        "open list:RISC-V ARCHITECTURE" <linux-riscv@...ts.infradead.org>,
        kexec@...ts.infradead.org,
        open list <linux-kernel@...r.kernel.org>,
        Torsten Duwe <duwe@...e.de>,
        Roberto Sassu <roberto.sassu@...weicloud.com>, petr@...arici.cz
Subject: Re: [PATCH v2 3/3] riscv/kexec: load initrd high in available memory

On 7/26/2023 6:38 PM, Conor Dooley wrote:
> On Wed, Jul 26, 2023 at 11:54:01AM +0200, Petr Tesarik wrote:
>> From: Torsten Duwe <duwe@...e.de>
>>
>> When initrd is loaded low, the secondary kernel fails like this:
>>
>>  INITRD: 0xdc581000+0x00eef000 overlaps in-use memory region
>>
>> This initrd load address corresponds to the _end symbol, but the
>> reservation is aligned on PMD_SIZE, as explained by a comment in
>> setup_bootmem().
>>
>> It is technically possible to align the initrd load address accordingly,
>> leaving a hole between the end of kernel and the initrd, but it is much
>> simpler to allocate the initrd top-down.
>>
>> Fixes: 838b3e28488f ("RISC-V: Load purgatory in kexec_file")
>> Signed-off-by: Torsten Duwe <duwe@...e.de>
>> Signed-off-by: Petr Tesarik <petr.tesarik.ext@...wei.com>
>> Cc: stable@...r.kernel.org
> 
> Trying to align it might be worthwhile, but the simple fix makes sense
> for now & w.r.t backporting.

On a second thought, allocating the initrd at the top of the range is
probably even better, because the kernel can unpack to low addresses,
resulting in less fragmented memory. See diagrams.

Top-down initrd:

+----------+          +----------+
|  initrd  |          |          |
+----------+          |   free   |
|          |          |          |
|          |  unpack  +----------+
|   free   |  ----->  | unpacked |
|          |          |  initrd  |
+----------+          +----------+
|  kernel  |          |  kernel  |
+----------+          +----------+


Aligned initrd:

+----------+          +----------+
|          |          |   free   |
|          |          +----------|
|   free   |          | unpacked |
|          |          |  initrd  |
+----------+  unpack  +----------+
|  initrd  |  ----->  |   free   |
+----------+          +----------+
|  kernel  |          |  kernel  |
+----------+          +----------+

Petr T