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: <a6a112d4-8fe7-4f73-b7c9-8eaf5e9d7ba1@huaweicloud.com>
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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ