All of lore.kernel.org
 help / color / mirror / Atom feed
From: Coiby Xu <coxu@redhat.com>
To: kexec@lists.infradead.org
Cc: Milan Broz <gmazyland@gmail.com>,
	Thomas Staudt <tstaudt@de.ibm.com>,
	Kairui Song <ryncsn@gmail.com>,
	dm-devel@redhat.com, Mike Snitzer <snitzer@redhat.com>,
	Baoquan He <bhe@redhat.com>, Dave Young <dyoung@redhat.com>,
	linux-kernel@vger.kernel.org
Subject: [RFC 0/4] Support kdump with LUKS encryption by reusing LUKS master key
Date: Fri, 18 Mar 2022 18:34:19 +0800	[thread overview]
Message-ID: <20220318103423.286410-1-coxu@redhat.com> (raw)

With kdump enabled, when kernel crashes, the system could boot into the
kdump kernel and dump the memory image i.e. /proc/vmcore to a specified
target. Currently, when dumping vmcore to a LUKS encrypted device, there
are two problems,
 - for some machines, the user may don't have a chance enter the password
   to decrypt the device after kernel crashes and kdump initrd is loaded
 - LUKS2 by default use the memory-hard Argon2 key derivation function
   which is quite memory-consuming compared to the limited memory reserved
   for kdump. Take Fedora example, by default, only 256M is reserved for
   systems having memory between 4G-64G. With LUKS enabled, ~1300M needs
   to be reserved for kdump.
 
Besides the users (at least for Fedora) usually expect kdump to work out
of the box i.e. no manual password input is needed. And it doesn't make
sense to derivate the master key again in kdump kernel which seems to be
redundant work.

Based on Milan's feedback [1] on Kairui's ideas to support kdump with
LUKS encryption, this patch set addresses the above issues by
 1) first saving the LUKS master key to kexec when opening the encrypted
    device 
 2) then saving the master key to the reserved memory for kdump when 
    loading kdump kernel image.

So the LUKS master key never leaves the kernel space and once the key has
been saved to the reserved memory for kdump, it would be wiped 
immediately. If there is no security concern with this approach or any
other concern, I will drop the following assumptions made for this RFC
version in v1,
 - only x86 is supported
 - there is only one LUKS device for the system

to extend the support to other architectures including POWER, ARM and
s390x and address the case of multiple LUKS devices. Any feedback will be 
appreciated, thanks!

For a proof of concept, I've patched cryptsetup [2] in a quick-and-dirty
way to support a new option "--kdump-kernel-master-key"
and hacked systemd [3]. It works for Fedora 34.

[1] https://yhbt.net/lore/all/e5abd089-3398-fdb4-7991-0019be434b79@gmail.com/
[2] https://gitlab.com/coxu/cryptsetup/-/commit/ee54bb15445da0bc3f9155a7227a9799da4dac20
[3] https://github.com/coiby/systemd/tree/reuse_kdump_master_key

Coiby Xu (4):
  kexec, dm-crypt: receive LUKS master key from dm-crypt and pass it to
    kdump
  kdump, x86: pass the LUKS master key to kdump kernel using a kernel
    command line parameter luksmasterkey
  crash_dump: retrieve LUKS master key in kdump kernel
  dm-crypt: reuse LUKS master key in kdump kernel

 arch/x86/include/asm/crash.h      |  1 +
 arch/x86/kernel/crash.c           | 42 ++++++++++++++++++-
 arch/x86/kernel/kexec-bzimage64.c |  7 ++++
 drivers/md/dm-crypt.c             | 26 +++++++++---
 include/linux/crash_dump.h        |  4 ++
 include/linux/kexec.h             |  7 ++++
 kernel/crash_dump.c               | 69 +++++++++++++++++++++++++++++++
 kernel/kexec_core.c               | 66 +++++++++++++++++++++++++++++
 8 files changed, 215 insertions(+), 7 deletions(-)

-- 
2.34.1


WARNING: multiple messages have this Message-ID (diff)
From: Coiby Xu <coxu@redhat.com>
To: kexec@lists.infradead.org
Cc: Mike Snitzer <snitzer@redhat.com>, Baoquan He <bhe@redhat.com>,
	dm-devel@redhat.com, linux-kernel@vger.kernel.org,
	Kairui Song <ryncsn@gmail.com>,
	Thomas Staudt <tstaudt@de.ibm.com>,
	Dave Young <dyoung@redhat.com>, Milan Broz <gmazyland@gmail.com>
Subject: [dm-devel] [RFC 0/4] Support kdump with LUKS encryption by reusing LUKS master key
Date: Fri, 18 Mar 2022 18:34:19 +0800	[thread overview]
Message-ID: <20220318103423.286410-1-coxu@redhat.com> (raw)

With kdump enabled, when kernel crashes, the system could boot into the
kdump kernel and dump the memory image i.e. /proc/vmcore to a specified
target. Currently, when dumping vmcore to a LUKS encrypted device, there
are two problems,
 - for some machines, the user may don't have a chance enter the password
   to decrypt the device after kernel crashes and kdump initrd is loaded
 - LUKS2 by default use the memory-hard Argon2 key derivation function
   which is quite memory-consuming compared to the limited memory reserved
   for kdump. Take Fedora example, by default, only 256M is reserved for
   systems having memory between 4G-64G. With LUKS enabled, ~1300M needs
   to be reserved for kdump.
 
Besides the users (at least for Fedora) usually expect kdump to work out
of the box i.e. no manual password input is needed. And it doesn't make
sense to derivate the master key again in kdump kernel which seems to be
redundant work.

Based on Milan's feedback [1] on Kairui's ideas to support kdump with
LUKS encryption, this patch set addresses the above issues by
 1) first saving the LUKS master key to kexec when opening the encrypted
    device 
 2) then saving the master key to the reserved memory for kdump when 
    loading kdump kernel image.

So the LUKS master key never leaves the kernel space and once the key has
been saved to the reserved memory for kdump, it would be wiped 
immediately. If there is no security concern with this approach or any
other concern, I will drop the following assumptions made for this RFC
version in v1,
 - only x86 is supported
 - there is only one LUKS device for the system

to extend the support to other architectures including POWER, ARM and
s390x and address the case of multiple LUKS devices. Any feedback will be 
appreciated, thanks!

For a proof of concept, I've patched cryptsetup [2] in a quick-and-dirty
way to support a new option "--kdump-kernel-master-key"
and hacked systemd [3]. It works for Fedora 34.

[1] https://yhbt.net/lore/all/e5abd089-3398-fdb4-7991-0019be434b79@gmail.com/
[2] https://gitlab.com/coxu/cryptsetup/-/commit/ee54bb15445da0bc3f9155a7227a9799da4dac20
[3] https://github.com/coiby/systemd/tree/reuse_kdump_master_key

Coiby Xu (4):
  kexec, dm-crypt: receive LUKS master key from dm-crypt and pass it to
    kdump
  kdump, x86: pass the LUKS master key to kdump kernel using a kernel
    command line parameter luksmasterkey
  crash_dump: retrieve LUKS master key in kdump kernel
  dm-crypt: reuse LUKS master key in kdump kernel

 arch/x86/include/asm/crash.h      |  1 +
 arch/x86/kernel/crash.c           | 42 ++++++++++++++++++-
 arch/x86/kernel/kexec-bzimage64.c |  7 ++++
 drivers/md/dm-crypt.c             | 26 +++++++++---
 include/linux/crash_dump.h        |  4 ++
 include/linux/kexec.h             |  7 ++++
 kernel/crash_dump.c               | 69 +++++++++++++++++++++++++++++++
 kernel/kexec_core.c               | 66 +++++++++++++++++++++++++++++
 8 files changed, 215 insertions(+), 7 deletions(-)

-- 
2.34.1

--
dm-devel mailing list
dm-devel@redhat.com
https://listman.redhat.com/mailman/listinfo/dm-devel


WARNING: multiple messages have this Message-ID (diff)
From: Coiby Xu <coxu@redhat.com>
To: kexec@lists.infradead.org
Subject: [RFC 0/4] Support kdump with LUKS encryption by reusing LUKS master key
Date: Fri, 18 Mar 2022 18:34:19 +0800	[thread overview]
Message-ID: <20220318103423.286410-1-coxu@redhat.com> (raw)

With kdump enabled, when kernel crashes, the system could boot into the
kdump kernel and dump the memory image i.e. /proc/vmcore to a specified
target. Currently, when dumping vmcore to a LUKS encrypted device, there
are two problems,
 - for some machines, the user may don't have a chance enter the password
   to decrypt the device after kernel crashes and kdump initrd is loaded
 - LUKS2 by default use the memory-hard Argon2 key derivation function
   which is quite memory-consuming compared to the limited memory reserved
   for kdump. Take Fedora example, by default, only 256M is reserved for
   systems having memory between 4G-64G. With LUKS enabled, ~1300M needs
   to be reserved for kdump.
 
Besides the users (at least for Fedora) usually expect kdump to work out
of the box i.e. no manual password input is needed. And it doesn't make
sense to derivate the master key again in kdump kernel which seems to be
redundant work.

Based on Milan's feedback [1] on Kairui's ideas to support kdump with
LUKS encryption, this patch set addresses the above issues by
 1) first saving the LUKS master key to kexec when opening the encrypted
    device 
 2) then saving the master key to the reserved memory for kdump when 
    loading kdump kernel image.

So the LUKS master key never leaves the kernel space and once the key has
been saved to the reserved memory for kdump, it would be wiped 
immediately. If there is no security concern with this approach or any
other concern, I will drop the following assumptions made for this RFC
version in v1,
 - only x86 is supported
 - there is only one LUKS device for the system

to extend the support to other architectures including POWER, ARM and
s390x and address the case of multiple LUKS devices. Any feedback will be 
appreciated, thanks!

For a proof of concept, I've patched cryptsetup [2] in a quick-and-dirty
way to support a new option "--kdump-kernel-master-key"
and hacked systemd [3]. It works for Fedora 34.

[1] https://yhbt.net/lore/all/e5abd089-3398-fdb4-7991-0019be434b79 at gmail.com/
[2] https://gitlab.com/coxu/cryptsetup/-/commit/ee54bb15445da0bc3f9155a7227a9799da4dac20
[3] https://github.com/coiby/systemd/tree/reuse_kdump_master_key

Coiby Xu (4):
  kexec, dm-crypt: receive LUKS master key from dm-crypt and pass it to
    kdump
  kdump, x86: pass the LUKS master key to kdump kernel using a kernel
    command line parameter luksmasterkey
  crash_dump: retrieve LUKS master key in kdump kernel
  dm-crypt: reuse LUKS master key in kdump kernel

 arch/x86/include/asm/crash.h      |  1 +
 arch/x86/kernel/crash.c           | 42 ++++++++++++++++++-
 arch/x86/kernel/kexec-bzimage64.c |  7 ++++
 drivers/md/dm-crypt.c             | 26 +++++++++---
 include/linux/crash_dump.h        |  4 ++
 include/linux/kexec.h             |  7 ++++
 kernel/crash_dump.c               | 69 +++++++++++++++++++++++++++++++
 kernel/kexec_core.c               | 66 +++++++++++++++++++++++++++++
 8 files changed, 215 insertions(+), 7 deletions(-)

-- 
2.34.1



             reply	other threads:[~2022-03-18 10:34 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-03-18 10:34 Coiby Xu [this message]
2022-03-18 10:34 ` [RFC 0/4] Support kdump with LUKS encryption by reusing LUKS master key Coiby Xu
2022-03-18 10:34 ` [dm-devel] " Coiby Xu
2022-03-18 10:34 ` [RFC 1/4] kexec, dm-crypt: receive LUKS master key from dm-crypt and pass it to kdump Coiby Xu
2022-03-18 10:34   ` Coiby Xu
2022-03-18 10:34   ` [dm-devel] " Coiby Xu
2022-03-18 10:34 ` [RFC 2/4] kdump, x86: pass the LUKS master key to kdump kernel using a kernel command line parameter luksmasterkey Coiby Xu
2022-03-18 10:34   ` Coiby Xu
2022-03-18 10:34   ` [dm-devel] " Coiby Xu
2022-03-18 10:34 ` [RFC 3/4] crash_dump: retrieve LUKS master key in kdump kernel Coiby Xu
2022-03-18 10:34   ` Coiby Xu
2022-03-18 10:34   ` [dm-devel] " Coiby Xu
2022-03-18 10:34 ` [RFC 4/4] dm-crypt: reuse " Coiby Xu
2022-03-18 10:34   ` Coiby Xu
2022-03-18 10:34   ` [dm-devel] " Coiby Xu
2022-03-18 11:29 ` [RFC 0/4] Support kdump with LUKS encryption by reusing LUKS master key Milan Broz
2022-03-18 11:29   ` Milan Broz
2022-03-18 11:29   ` [dm-devel] " Milan Broz
2022-03-18 12:21   ` Coiby Xu
2022-03-18 12:21     ` Coiby Xu
2022-03-18 12:21     ` [dm-devel] " Coiby Xu
2022-03-18 13:53     ` Milan Broz
2022-03-18 13:53       ` Milan Broz
2022-03-18 13:53       ` [dm-devel] " Milan Broz
2022-03-19  1:41       ` Coiby Xu
2022-03-19  1:41         ` Coiby Xu
2022-03-19  1:41         ` [dm-devel] " Coiby Xu
2022-03-19 20:13 ` Guilherme G. Piccoli
2022-03-19 20:13   ` Guilherme G. Piccoli
2022-03-19 20:13   ` [dm-devel] " Guilherme G. Piccoli
2022-03-21  1:41   ` Coiby Xu
2022-03-21  1:41     ` Coiby Xu
2022-03-21  1:41     ` [dm-devel] " Coiby Xu
2022-03-21 12:28     ` Guilherme G. Piccoli
2022-03-21 12:28       ` Guilherme G. Piccoli
2022-03-21 12:28       ` [dm-devel] " Guilherme G. Piccoli

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20220318103423.286410-1-coxu@redhat.com \
    --to=coxu@redhat.com \
    --cc=bhe@redhat.com \
    --cc=dm-devel@redhat.com \
    --cc=dyoung@redhat.com \
    --cc=gmazyland@gmail.com \
    --cc=kexec@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=ryncsn@gmail.com \
    --cc=snitzer@redhat.com \
    --cc=tstaudt@de.ibm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.