[PATCH 00/11] crashkernel=auto: support fadump, reserve extra SWIOTLB memory and remove crashkernel.default
by Coiby Xu
The crashkernel=auto implementation in kernel space has been rejected
upstream [1]. The current user space implementation [2] [3] ships a
crashkernel.default but hasn't supported the swiotlb memory requirement,
custom crashkernel value from user and fadump.
The crashkernel.default implementation seems to be overly
complex,
- the default crashkernel value rarely changes. This is no need to ship
the same crashkernel.default default for every kernel package of a
architecture;
- when deciding the value of crashkernel for a new kernel, the
crashkernel.default of existing kernel is took into consideration
We can simply let the kexec-tools maintain the default crashkernel
values and provide an API for kdump-anacon-addon to query it. And for
a newly installed kernel, we can simply call "kdumpctl reset-crashkernel
KERNELPATH" to set its crashkernel value.
For the unfulfilled requirements,
- crashkernel is introduced to /etc/kdump.conf for the user can set
custom crashkernel value to tell kexec-tools to manage crashkernel
value automatically.
- "kdumpctl reset-crashkernel" has been written for the above
purpose.
- "kdumpctl fadump on/off" is added for supporting fadump.
[1] https://lore.kernel.org/linux-mm/20210507010432.IN24PudKT%25akpm@linux-fo...
[2] https://gitlab.com/cki-project/kernel-ark/-/merge_requests/1171
[3] https://lists.fedoraproject.org/archives/list/kexec@lists.fedoraproject.o...
Coiby Xu (11):
update default crashkernel value
factor out kdump_get_arch_recommend_crashkernel
provide get_default_crashkernel for kdump_anaconda_addon
introduce crashkernel option to kdump.conf
add a helper function to write a config value to kdump.conf
add a helper function to read kernel cmdline parameter from grubby
--info
rewrite reset_crashkernel to provide more features for the user and to
be called by kernel installation hook
allow to add extra memory to crashkernel string
Reserve extra memory when SME or SEV is active
provide kdumpctl fadump on/off
use "kdumpctl reset-crashkernel KERNELIMAGE" in kernel installation
hook
92-crashkernel.install | 135 +----------------------------
kdump-lib-initramfs.sh | 9 ++
kdump-lib.sh | 95 +++++++++++++++------
kdump.conf | 6 ++
kdump.conf.5 | 7 ++
kdumpctl | 188 ++++++++++++++++++++++++++++++++++++-----
kdumpctl.8 | 16 ++--
7 files changed, 271 insertions(+), 185 deletions(-)
--
2.31.1
1 year, 3 months
[PATCH] mkdumprd: allow spaces after 'path' config phrase when network dump
by Kazuhito Hagio
Without this patch, when there are two or more spaces after 'path'
configuration phrase with ssh or nfs setting, SAVE_PATH is set to
'/var/crash' in mkdumprd, and in most cases kdump service fails to
start.
ssh kdump(a)192.168.122.1
path /kdump
^^
This behavior would be too sensitive and different from the other
configurations. With this patch, mkdumprd allows such spaces.
Signed-off-by: Kazuhito Hagio <k-hagio(a)ab.jp.nec.com>
---
mkdumprd | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/mkdumprd b/mkdumprd
index a6f7fe8..aa0abfd 100644
--- a/mkdumprd
+++ b/mkdumprd
@@ -13,7 +13,7 @@ export IN_KDUMP=1
conf_file="/etc/kdump.conf"
SSH_KEY_LOCATION="/root/.ssh/kdump_id_rsa"
-SAVE_PATH=$(grep ^path $conf_file| cut -d' ' -f2)
+SAVE_PATH=$(awk '/^path/ {print $2}' $conf_file)
[ -z "$SAVE_PATH" ] && SAVE_PATH=$DEFAULT_PATH
# strip the duplicated "/"
SAVE_PATH=$(echo $SAVE_PATH | tr -s /)
--
2.18.0
1 year, 4 months
[kdump-anaconda-addon] Could you share you kickstart .cfg file?
by Coiby Xu
Hi Kairui,
I have a question about testing kdump-anaconda-addon. I used virt-install
to start the installation,
$ virt-install --ram 2048 --location https://mirrors.ustc.edu.cn/fedora/releases/35/Server/x86_64/os/ \
--disk=kdump_b.img,format=qcow2,bus=virtio --extra-args="inst.updates=http://172.31.9.95:8000/updates.img"
The problem is it somehow takes several minutes for the installation GUI
window to appear. If I use --cdrom RHEL9-xxx.iso, the GUI window would
appear very fast but --cdrom it doesn't support --extra-args and I have
to manually edit the boot menu to add inst.updates=. I remember you
use kickstart to test the kdump addon. Could you share you kickstart
.cfg file so I may find out what's wrong with my way? Thanks!
--
Best regards,
Coiby
1 year, 10 months
[PATCH] add keytuils as a weak dependency for POWER
by Coiby Xu
When secureboot is enabled, kdumpctl needs to use keyctl to add/remove
a key to/from the .ima keyring.
Fixes: commit 596fa0a07f089a9dd54cf631124d88653b4d77ec
("kdumpctl: enable secure boot on ppc64le LPARs")
Signed-off-by: Coiby Xu <coxu(a)redhat.com>
---
kexec-tools.spec | 1 +
1 file changed, 1 insertion(+)
diff --git a/kexec-tools.spec b/kexec-tools.spec
index 8efc17a..dcab391 100644
--- a/kexec-tools.spec
+++ b/kexec-tools.spec
@@ -63,6 +63,7 @@ Source201: dracut-fadump-module-setup.sh
%ifarch ppc64 ppc64le
Requires(post): servicelog
+Recommends: keyutils
%endif
Requires(pre): coreutils sed zlib
Requires: dracut >= 050
--
2.31.1
1 year, 10 months
[PATCHv2] Document/kexec-kdump-howto.txt: improve notes for kdump_pre and kdump_post scripts
by Pingfan Liu
Signed-off-by: Pingfan Liu <piliu(a)redhat.com>
---
kdump.conf.5 | 14 ++++++++++----
kexec-kdump-howto.txt | 6 ++++++
2 files changed, 16 insertions(+), 4 deletions(-)
diff --git a/kdump.conf.5 b/kdump.conf.5
index 2c5a2bc..6e6cafa 100644
--- a/kdump.conf.5
+++ b/kdump.conf.5
@@ -118,8 +118,11 @@ All files under /etc/kdump/post.d are collectively sorted
and executed in lexical order, before binary or script
specified kdump_post parameter is executed.
.PP
-Note that scripts written for use with this directive must use
-the /bin/bash interpreter.
+Note that scripts written for use with this directive must use the /bin/bash
+interpreter. And since these scripts run in kdump enviroment, the reference to
+the storage or network device in the scripts should adhere to the section
+'Supported dump target types and requirements' in kexec-kdump-howto.txt.
+
.RE
.B kdump_pre <binary | script>
@@ -139,8 +142,11 @@ kdump_pre parameter is executed.
Even if the binary or script in /etc/kdump/pre.d directory
returns non 0 exit status, the processing is continued.
.PP
-Note that scripts written for this directive must use
-the /bin/bash interpreter.
+Note that scripts written for use with this directive must use the /bin/bash
+interpreter. And since these scripts run in kdump enviroment, the reference to
+the storage or network device in the scripts should adhere to the section
+'Supported dump target types and requirements' in kexec-kdump-howto.txt.
+
.RE
.B extra_bins <binaries | shell scripts>
diff --git a/kexec-kdump-howto.txt b/kexec-kdump-howto.txt
index 88af607..1aeffc7 100644
--- a/kexec-kdump-howto.txt
+++ b/kexec-kdump-howto.txt
@@ -621,6 +621,9 @@ If /etc/kdump/post.d directory exist, All files in the directory are
collectively sorted and executed in lexical order, before binary or script
specified kdump_post parameter is executed.
+In these scripts, the reference to the storage or network device should adhere
+to the section 'Supported dump target types and requirements'
+
Kdump Pre-Capture Executable
----------------------------
@@ -634,6 +637,9 @@ kdump_pre parameter is executed.
Even if the binary or script in /etc/kdump/pre.d directory returns non 0
exit status, the processing is continued.
+In these scripts, the reference to the storage or network device should adhere
+to the section 'Supported dump target types and requirements'
+
Extra Binaries
--------------
--
2.31.1
1 year, 10 months
[PATCH] Document/kexec-kdump-howto.txt: improve notes for kdump_pre and kdump_post scripts
by Pingfan Liu
Signed-off-by: Pingfan Liu <piliu(a)redhat.com>
---
kdump.conf.5 | 7 +++++--
kexec-kdump-howto.txt | 6 ++++++
2 files changed, 11 insertions(+), 2 deletions(-)
diff --git a/kdump.conf.5 b/kdump.conf.5
index 2c5a2bc..385ae3e 100644
--- a/kdump.conf.5
+++ b/kdump.conf.5
@@ -118,8 +118,11 @@ All files under /etc/kdump/post.d are collectively sorted
and executed in lexical order, before binary or script
specified kdump_post parameter is executed.
.PP
-Note that scripts written for use with this directive must use
-the /bin/bash interpreter.
+Note that scripts written for use with this directive must use the /bin/bash
+interpreter. And since these scripts run in kdump enviroment, the reference to
+the storage or network device in the scripts should adhere to the section
+'Supported dump target types and requirements' in kexec-kdump-howto.txt.
+
.RE
.B kdump_pre <binary | script>
diff --git a/kexec-kdump-howto.txt b/kexec-kdump-howto.txt
index 88af607..1aeffc7 100644
--- a/kexec-kdump-howto.txt
+++ b/kexec-kdump-howto.txt
@@ -621,6 +621,9 @@ If /etc/kdump/post.d directory exist, All files in the directory are
collectively sorted and executed in lexical order, before binary or script
specified kdump_post parameter is executed.
+In these scripts, the reference to the storage or network device should adhere
+to the section 'Supported dump target types and requirements'
+
Kdump Pre-Capture Executable
----------------------------
@@ -634,6 +637,9 @@ kdump_pre parameter is executed.
Even if the binary or script in /etc/kdump/pre.d directory returns non 0
exit status, the processing is continued.
+In these scripts, the reference to the storage or network device should adhere
+to the section 'Supported dump target types and requirements'
+
Extra Binaries
--------------
--
2.31.1
1 year, 10 months
[PATCH 0/2] sysconfig: make kexec_file_load as default option
by Pingfan Liu
Pingfan Liu (2):
sysconfig: make kexec_file_load as default option on aarch64
sysconfig: make kexec_file_load as default option on ppc64le
kdump.sysconfig.aarch64 | 2 +-
kdump.sysconfig.ppc64le | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
--
2.31.1
1 year, 10 months
[rawhide PATCH] Enable zstd compression for makedumpfile in kexec-tools.spec
by Tao Liu
The Zstandard (zstd) compression method is not enabled:
$ makedumpfile -v
makedumpfile: version 1.7.0 (released on 8 Nov 2021)
lzo enabled
snappy enabled
zstd disabled
This patch will enable it when building kexec-tools rpm package.
Signed-off-by: Tao Liu <ltao(a)redhat.com>
---
kexec-tools.spec | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/kexec-tools.spec b/kexec-tools.spec
index 331d61d..8efc17a 100644
--- a/kexec-tools.spec
+++ b/kexec-tools.spec
@@ -71,7 +71,7 @@ Requires: dracut-squash >= 050
Requires: ethtool
Recommends: grubby
BuildRequires: make
-BuildRequires: zlib-devel elfutils-devel glib2-devel bzip2-devel ncurses-devel bison flex lzo-devel snappy-devel
+BuildRequires: zlib-devel elfutils-devel glib2-devel bzip2-devel ncurses-devel bison flex lzo-devel snappy-devel libzstd-devel
BuildRequires: pkgconfig intltool gettext
BuildRequires: systemd-rpm-macros
BuildRequires: automake autoconf libtool
@@ -151,7 +151,7 @@ cp %{SOURCE34} .
make
%ifarch %{ix86} x86_64 ppc64 s390x ppc64le aarch64
make -C eppic-%{eppic_ver}/libeppic
-make -C makedumpfile-%{mkdf_ver} LINKTYPE=dynamic USELZO=on USESNAPPY=on
+make -C makedumpfile-%{mkdf_ver} LINKTYPE=dynamic USELZO=on USESNAPPY=on USEZSTD=on
make -C makedumpfile-%{mkdf_ver} LDFLAGS="$LDFLAGS -I../eppic-%{eppic_ver}/libeppic -L../eppic-%{eppic_ver}/libeppic" eppic_makedumpfile.so
%endif
--
2.29.2
1 year, 10 months
Re: [dm-crypt] Kdump with full-disk LUKS encryption
by Kairui Song
Hi,
Thanks a lot, these info are very helpful.
Better to keep it for debugging for now, and ask users to use it very carefully.
On Tue, Apr 20, 2021 at 3:54 PM Milan Broz <gmazyland(a)gmail.com> wrote:
>
> Hi,
>
> TL;DR what you are trying to do is to actually reverse many security measures
> we added. It is perhaps acceptable for debugging but hardly for real generic system.
>
> - using memory-hard function increases cost of dictionary and brute-force
> attacks
> You can always decrease amount of memory needed, but you should do it only
> if you know that security margin is ok (like password is randomly generated
> with enough entropy).
>
> - key is in keyring to remove possibility for normal userspace to receive
> the key from kernel. Moreover, there is no need to retain kernel in keyring once
> dm-crypt device is activated. (It is still in kernel memory but only in crypto
> functions context). (Systemd also uses keyring to cache passphrase but that's
> different thing.)
>
> You can still use old way for activation with --disable-keyring activation,
> but then you disable this possibility.
>
> More comments below.
>
> On 19/04/2021 12:00, Kairui Song wrote:
> > Hi all,
> >
> > I'm currently trying to add kdump support for systemd with full-disk
> > LUKS encryption. vmcores contain sensitive data so they should also be
> > protected, and network dumps sometimes are not available. So kdump has
> > to open the LUKS encrypted device in the kdump environment.
> >
> > I'm using systemd/dracut, my work machine is running Fedora 34, and
> > there are several problems I'm trying to solve:
> > 1. Users have to input the password in the kdump kernel environment.
> > But users often don't have shell access to the kdump environment.
> > (headless server, graphic card not working after kexec, both are very
> > common)
> > 2. LUKS2 prefers Argon2 as the key derivation function, designed to
> > use a lot of memory. kdump is expected to use a minimal amount of
> > memory. Users will have to reserve a huge amount of memory for kdump
> > to work (eg. 1G reserve for kdump with 4G total memory which is not
> > reasonable).
>
> When I added Argon2 to LUKS2, I actually expected such issues. Despite
> some people beats me that they cannot use arbitrary amount of memory,
> we have some hard limits that were selected that it should work on most recent
> systems. Maybe kdump can live with it.
>
> - maximum memory cost limit is 4GB, no LUKS2 device can use more for Argon2
> - we never use more than half of available physical memory
> (measured on the host where the device was formatted)
> - required amount of memory is visible in LUKS2 metadata (luksDump)
> for the particular keyslot (Memory: the value is in kB)
> - we use benchmark to calculate memory cost with prefered unlocking
> time 2 seconds (again, on the device where LUKS was formatted)
> Small systems (like RPi2) the uses much smaller acceptable values.
> You can configure all costs (time, memory, threads) during format
> or even set them to predefined values.
>
> I am sorry, but there is really no way around this - and the requeired
> memory must be physical memory (otherwise it slows down extremely).
> This is a feature, not a bug :-)
>
>
> > To fix these problems, I tried to pass the master key to the second
> > kernel directly via initramfs. Kdump will modify the initramfs in
> > ramfs to include the key, kexec_load it, and never write to any actual
> > back storage. This worked with old LUKS configurations.
>
> Well, passing volume key this way is quite insecure, but perhaps
> acceptable for debugging.
>
> >
> > But LUKS2/cryptsetup now stores the key in the kernel keyring by
> > default. The key is accessible from userspace.
>
> If you are talking about volume key (not passsphrase), it is not
> available from userspace. Only reference to it. But you can use
> this reference to construct in-kernel dm-crypt device.
> Please read https://gitlab.com/cryptsetup/cryptsetup/-/blob/master/docs/Keyring.txt
>
> > Users can enter the password to start kdump manually and then it will
> > work, but usually people expect kdump service to start automatically.
> >
> > (WIP patch series:
> > https://lists.fedoraproject.org/archives/list/kexec@lists.fedoraproject.o...)
> >
> > I've several ideas about how to improve it but not sure which one is
> > better, and if this is a good idea after all:
> > 1. Simply introduce a config to let systemd-cryptsetup disable kernel
> > keyring on setup, there is currently no such option.
>
> Well, that option could be useful anyway and we have support for it
> in cryptsetup (--disable-keyring CLI option) and libcryptsetup, so why not.
> Just this should not be a default option.
>
> This is should be patch for systemd-cryptsetup only as libcryptsetup supports it.
>
> ...
>
> > 2. If we can let the key stay in userspace for a little longer, eg.
> > for systems booted with dracut/systemd, when
> > systemd-cryptsetup(a)%s.service opens the crypt device, keep the key in
> > dm-crypt. And later when services like kdump have finished loading,
> > cryptsetup can refresh the device and store the key in the kernel
> > keyring again.
>
> We invalidate volume key in keyring after libceyposetup operation
> is finished (and kernel removes the reference once keyring garbage collection
> is run).
>
> I can imagine to add some option to keep key inside keyring even after
> call is finished, but as said above, this removes some security margin
> we intentionally introduced here.
I agree with your comments, thanks! These two approaches seem not a
good idea now.
>
> ...
>
> Milan
>
How about plan 3 and 4?
> 3. Let kdump use some custom helper/service to load all needed
> resources in the early initrd boot stage, prior to
> systemd-cryptsetup(a)%s.service. It will ask the password / parse the
> keyfile and load kdump, then provide info for systemd-cryptsetup or
> just do the setup. Or maybe let systemd-cryptsetup support some kind
> of "plugins" so other tools can use it.
Some details could be changed/improved, but
systemd-cryptsetup(a)%s.service will prompt for a password or use a
keyfile anyway.
So I think at this point, loading kdump with the volume key should be
safe? At least long as the kdump kernel/environment itself isn't
compromised. Loaded kdump resources can be restricted to be only
accessible from the kernel side.
After panic, kernel kexec jumps to kdump kernel, and that's an
minimized emergency environment that only lives for a very short
period.
> 4. A better and safer solution seems to keep a consistent key ring
> between kexec boots but also more complex and difficult as different
> arch implements kexec differently.
Maybe plan 4 will be a good idea if doable? Since that keeps the key
consistent in the kernel between kexec boots, and cryptsetup can just
reuse it.
--
Best Regards,
Kairui Song
1 year, 11 months
[PATCH] fix broken extra_bins when installing multiple binaries
by Coiby Xu
When there more than one binaries, quoting "$val" would make
dracut-install treat multiple binaries as one binary. Take
"extra_bins /usr/sbin/ping /usr/sbin/ip" as an example, the
following error would occur when building initrd,
dracut-install: ERROR: installing '/usr/sbin/ping /usr/sbin/ip'
dracut: FAILED: /usr/lib/dracut/dracut-install -D /var/tmp/dracut.ODrioZ/initramfs -a /usr/sbin/ping /usr/sbin/ip
Fix it by not quoting the variable and bypassing SC2086 shellcheck.
Fixes: commit 86538ca6e2e555caa8cdd2bcfcc3c5e94ac6bf58
("bash scripts: fix variable quoting issue")
Signed-off-by: Coiby Xu <coxu(a)redhat.com>
---
dracut-module-setup.sh | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/dracut-module-setup.sh b/dracut-module-setup.sh
index a5e4b67..1ea0d95 100755
--- a/dracut-module-setup.sh
+++ b/dracut-module-setup.sh
@@ -686,7 +686,8 @@ kdump_install_conf() {
fi
;;
kdump_pre | kdump_post | extra_bins)
- dracut_install "$_val"
+ # shellcheck disable=SC2086
+ dracut_install $_val
;;
core_collector)
dracut_install "${_val%%[[:blank:]]*}"
--
2.31.1
1 year, 11 months