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-next>] [day] [month] [year] [list]
Message-Id: <20210526190531.62751-1-maz@kernel.org>
Date:   Wed, 26 May 2021 20:05:27 +0100
From:   Marc Zyngier <maz@...nel.org>
To:     kexec@...ts.infradead.org, linux-arm-kernel@...ts.infradead.org,
        linux-kernel@...r.kernel.org
Cc:     Catalin Marinas <catalin.marinas@....com>,
        Will Deacon <will@...nel.org>,
        Ard Biesheuvel <ardb@...nel.org>,
        Mark Rutland <mark.rutland@....com>,
        James Morse <james.morse@....com>,
        Lorenzo Pieralisi <lorenzo.pieralisi@....com>,
        Hanjun Guo <guohanjun@...wei.com>,
        Sudeep Holla <sudeep.holla@....com>,
        Eric Biederman <ebiederm@...ssion.com>,
        Bhupesh SHARMA <bhupesh.sharma@...aro.org>,
        AKASHI Takahiro <takahiro.akashi@...aro.org>,
        Dave Young <dyoung@...hat.com>,
        Moritz Fischer <mdf@...nel.org>, kernel-team@...roid.com
Subject: [PATCH 0/4] arm64: Make kexec_file_load honor iomem reservations

This series is a complete departure from the approach I initially sent
almost a month ago[1]. Instead of trying to teach EFI, ACPI and other
subsystem to use memblock, I've decided to stick with the iomem
resource tree and use that exclusively for arm64.

This means that my current approach is (despite what I initially
replied to both Dave and Catalin) to provide an arm64-specific
implementation of arch_kexec_locate_mem_hole() which walks the
resource tree and excludes ranges of RAM that have been registered for
any odd purpose. This is exactly what the userspace implementation
does, and I don't really see a good reason to diverge from it.

Again, this allows my Synquacer board to reliably use kexec_file_load
with as little as 256M, something that would always fail before as it
would overwrite most of the reserved tables.

Obviously, this is now at least 5.14 material. Given how broken
kexec_file_load is for non-crash kernels on arm64 at the moment,
should we at least disable it in 5.13 and all previous stable kernels?

Thanks,

	M.

[1] https://lore.kernel.org/r/20210429133533.1750721-1-maz@kernel.org

Marc Zyngier (4):
  kexec_file: Make locate_mem_hole_callback global
  kernel/resource: Populate child pointer in find_next_iomem_res()
  kernel/resource: Add walk_excluding_child_res() helper
  arm64: kexec_image: Implement arch_kexec_locate_mem_hole()

 arch/arm64/kernel/kexec_image.c | 45 ++++++++++++++++++
 include/linux/ioport.h          |  4 ++
 include/linux/kexec.h           |  1 +
 kernel/kexec_file.c             |  6 +--
 kernel/resource.c               | 81 +++++++++++++++++++++++++++++++++
 5 files changed, 134 insertions(+), 3 deletions(-)

-- 
2.30.2

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ