linux-kernel - Re: [PATCH] crash: Default to CRASH_DUMP=n when support for it is unlikely

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: <87frqsghws.fsf@mail.lhotse>
Date: Mon, 26 Aug 2024 12:02:59 +1000
From: Michael Ellerman <mpe@...erman.id.au>
To: Geert Uytterhoeven <geert@...ux-m68k.org>, Dave Vasilevsky
 <dave@...ilevsky.ca>
Cc: glaubitz@...sik.fu-berlin.de, bhe@...hat.com,
 linuxppc-dev@...ts.ozlabs.org, linux-sh@...r.kernel.org,
 kexec@...ts.infradead.org, linux-kernel@...r.kernel.org, Reimar
 Döffinger
 <Reimar.Doeffinger@....de>
Subject: Re: [PATCH] crash: Default to CRASH_DUMP=n when support for it is
 unlikely

Geert Uytterhoeven <geert@...ux-m68k.org> writes:
> Hi Dave,
>
> On Fri, Aug 23, 2024 at 2:54 PM Dave Vasilevsky <dave@...ilevsky.ca> wrote:
>> Fixes boot failures on 6.9 on PPC_BOOK3S_32 machines using
>> Open Firmware. On these machines, the kernel refuses to boot
>> from non-zero PHYSICAL_START, which occurs when CRASH_DUMP is on.
>>
>> Since most PPC_BOOK3S_32 machines boot via Open Firmware, it should
>> default to off for them. Users booting via some other mechanism
>> can still turn it on explicitly.
>>
>> Also defaults to CRASH_DUMP=n on sh.
>>
>> Signed-off-by: Dave Vasilevsky <dave@...ilevsky.ca>
>> Reported-by: Reimar Döffinger <Reimar.Doeffinger@....de>
>> Closes: https://lists.debian.org/debian-powerpc/2024/07/msg00001.html
>> Fixes: 75bc255a7444 ("crash: clean up kdump related config items")
>
> Thanks for your patch!
>
>> --- a/kernel/Kconfig.kexec
>> +++ b/kernel/Kconfig.kexec
>> @@ -97,7 +97,7 @@ config KEXEC_JUMP
>>
>>  config CRASH_DUMP
>>         bool "kernel crash dumps"
>> -       default y
>> +       default ARCH_DEFAULT_CRASH_DUMP
>>         depends on ARCH_SUPPORTS_CRASH_DUMP
>>         depends on KEXEC_CORE
>>         select VMCORE_INFO
>
> IMHO CRASH_DUMP should just default to n, like most kernel options, as
> it enables non-trivial extra functionality: the kernel source tree has
> more than 100 locations that check if CONFIG_CRASH_DUMP is enabled.
>
> Letting it default to enabled also conflicts with the spirit of the
> help text for the symbol:
>
>           Generate crash dump after being started by kexec.
>           This should be normally only set in special crash dump kernels
>           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>           which are loaded in the main kernel with kexec-tools into
>           a specially reserved region and then later executed after
>           a crash by kdump/kexec. The crash dump kernel must be compiled
>           to a memory address not used by the main kernel or BIOS using
>           PHYSICAL_START, or it must be built as a relocatable image
>           (CONFIG_RELOCATABLE=y).
>           For more details see Documentation/admin-guide/kdump/kdump.rst
>
>           For s390, this option also enables zfcpdump.
>           See also <file:Documentation/arch/s390/zfcpdump.rst>
>
> What is so special about CRASH_DUMP, that it should be enabled by
> default?
 
The reality is that essentially all distros enable it. Because they
don't want to manage separate kernel / crash-kernel packages.

So IMHO having it enabled by default in upstream does make sense,
because it more closely matches what distros/users actually run.

cheers