linux-kernel - Re: [PATCH v6 1/7] arm64: mm: Move reserve_crashkernel() into mem

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: <88c69ac0c9d7e144c80cebc7e9f82b000828e7f5.camel@suse.de>
Date:   Fri, 06 Nov 2020 19:46:29 +0100
From:   Nicolas Saenz Julienne <nsaenzjulienne@...e.de>
To:     James Morse <james.morse@....com>
Cc:     robh+dt@...nel.org, catalin.marinas@....com, hch@....de,
        ardb@...nel.org, linux-kernel@...r.kernel.org,
        devicetree@...r.kernel.org, lorenzo.pieralisi@....com,
        will@...nel.org, jeremy.linton@....com,
        iommu@...ts.linux-foundation.org,
        linux-rpi-kernel@...ts.infradead.org, guohanjun@...wei.com,
        robin.murphy@....com, linux-arm-kernel@...ts.infradead.org
Subject: Re: [PATCH v6 1/7] arm64: mm: Move reserve_crashkernel() into
 mem_init()

Hi James, thanks for the review. Some comments/questions below.

On Thu, 2020-11-05 at 16:11 +0000, James Morse wrote:
> Hi!
> 
> On 03/11/2020 17:31, Nicolas Saenz Julienne wrote:
> > crashkernel might reserve memory located in ZONE_DMA. We plan to delay
> > ZONE_DMA's initialization after unflattening the devicetree and ACPI's
> > boot table initialization, so move it later in the boot process.
> > Specifically into mem_init(), this is the last place crashkernel will be
> > able to reserve the memory before the page allocator kicks in.
> > There
> > isn't any apparent reason for doing this earlier.
> 
> It's so that map_mem() can carve it out of the linear/direct map.
> This is so that stray writes from a crashing kernel can't accidentally corrupt the kdump
> kernel. We depend on this if we continue with kdump, but failed to offline all the other
> CPUs.

I presume here you refer to arch_kexec_protect_crashkres(), IIUC this will only
happen further down the line, after having loaded the kdump kernel image. But
it also depends on the mappings to be PAGE sized (flags == NO_BLOCK_MAPPINGS |
NO_CONT_MAPPINGS).

> We also depend on this when skipping the checksum code in purgatory, which can be
> exceedingly slow.

This one I don't fully understand, so I'll lazily assume the prerequisite is
the same WRT how memory is mapped. :)

Ultimately there's also /sys/kernel/kexec_crash_size's handling. Same
prerequisite.

Keeping in mind acpi_table_upgrade() and unflatten_device_tree() depend on
having the linear mappings available. I don't see any simple way of solving
this. Both moving the firmware description routines to use fixmap or correcting
the linear mapping further down the line so as to include kdump's regions, seem
excessive/impossible (feel free to correct me here). I'd be happy to hear
suggestions. Otherwise we're back to hard-coding the information as we
initially did.

Let me stress that knowing the DMA constraints in the system before reserving
crashkernel's regions is necessary if we ever want it to work seamlessly on all
platforms. Be it small stuff like the Raspberry Pi or huge servers with TB of
memory.

Regards,
Nicolas

Download attachment "signature.asc" of type "application/pgp-signature" (489 bytes)