Re: Potential config regression after 89cde455 ("kexec: consolidate kexec and crash options into kernel/Kconfig.kexec")

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, Nov 21, 2023 at 1:50 AM Baoquan He <bhe@xxxxxxxxxx> wrote:

Eric DeVolder's Oracle mail address is not available anymore, add his
current mail address he told me.

Thank you!

On 11/20/23 at 10:52pm, Ignat Korchagin wrote:
Good day!

We have recently started to evaluate Linux 6.6 and noticed that we
cannot disable CONFIG_KEXEC anymore, but keep CONFIG_CRASH_DUMP
enabled. It seems to be related to commit 89cde455 ("kexec:
consolidate kexec and crash options into kernel/Kconfig.kexec"), where
a CONFIG_KEXEC dependency was added to CONFIG_CRASH_DUMP.

In our current kernel (Linux 6.1) we only enable CONFIG_KEXEC_FILE
with enforced signature check to support the kernel crash dumping
functionality and would like to keep CONFIG_KEXEC disabled for
security reasons [1].

I was reading the long commit message, but the reason for adding
CONFIG_KEXEC as a dependency for CONFIG_CRASH_DUMP evaded me. And I
believe from the implementation perspective CONFIG_KEXEC_FILE should
suffice here (as we successfully used it for crashdumps on Linux 6.1).

Is there a reason for adding this dependency or is it just an
oversight? Would some solution of requiring either CONFIG_KEXEC or
CONFIG_KEXEC_FILE work here?

I searched the patch history, found Eric didn't add the dependency on
CONFIG_KEXEC at the beginning. Later a linux-next building failure with
randconfig was reported, in there CONFIG_CRASH_DUMP enabled, while
CONFIG_KEXEC is disabled. Finally Eric added the KEXEC dependency for
CRASH_DUMP. Please see below link for more details:

https://lore.kernel.org/all/3e8eecd1-a277-2cfb-690e-5de2eb7b988e@xxxxxxxxxx/T/#u

Thank you for digging this up. However I'm still confused, because
this is exactly how we configure Linux 6.1 (although we do have
CONFIG_KEXEC_FILE enabled) and we don't have any problems. I believe
we did not investigate this issue properly.

And besides, the newly added CONFIG_CRASH_HOTPLUG also needs
CONFIG_KEXEC if the elfcorehdr is allowed to be manipulated when
cpu/memory hotplug hapened.

This still feels like a regression to me: any crash dump support
should be independent of KEXEC syscalls being present. While probably
the common case (including us) that the crashing kernel and recovery
kernel are the same, they don't have to be. We need kexec syscall in
the crashing kernel, but crashdump support in the recovery kernel (but
the recovery kernel not having the kexec syscalls should be totally
fine). If we do require some code definitions from kexec - at most we
should put them under CONFIG_KEXEC_CORE.

Thanks
Baoquan





[Index of Archives]     [Video for Linux]     [Yosemite News]     [Linux S/390]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux