From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <SRS0=l03m=JQ=saout.de=dm-crypt-bounces@kernel.org>
X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on
	aws-us-west-2-korg-lkml-1.web.codeaurora.org
X-Spam-Level: 
X-Spam-Status: No, score=-3.5 required=3.0 tests=BAYES_00,DKIM_INVALID,
	DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,
	SPF_PASS,URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0
Received: from mail.kernel.org (mail.kernel.org [198.145.29.99])
	by smtp.lore.kernel.org (Postfix) with ESMTP id 80519C433ED
	for <dm-crypt@archiver.kernel.org>; Mon, 19 Apr 2021 18:17:25 +0000 (UTC)
Received: from mail.server123.net (mail.server123.net [78.46.64.186])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(No client certificate requested)
	by mail.kernel.org (Postfix) with ESMTPS id DEC3D611EE
	for <dm-crypt@archiver.kernel.org>; Mon, 19 Apr 2021 18:17:24 +0000 (UTC)
DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org DEC3D611EE
Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=redhat.com
Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=dm-crypt-bounces@saout.de
X-Virus-Scanned: amavisd-new at saout.de
Authentication-Results: mail.server123.net (amavisd-new);
	dkim=pass (1024-bit key) header.d=redhat.com
Received-SPF: Pass (mailfrom) identity=mailfrom; client-ip=216.205.24.124; helo=us-smtp-delivery-124.mimecast.com; envelope-from=kasong@redhat.com; receiver=<UNKNOWN> 
X-Greylist: delayed 310 seconds by postgrey-1.37 at siona; Mon, 19 Apr 2021 12:07:23 CEST
Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [216.205.24.124])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(No client certificate requested)
	by mail.server123.net (Postfix) with ESMTPS
	for <dm-crypt@saout.de>; Mon, 19 Apr 2021 12:07:22 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com;
	s=mimecast20190719; t=1618826841;
	h=from:from:reply-to:subject:subject:date:date:message-id:message-id:
	 to:to:cc:mime-version:mime-version:content-type:content-type;
	bh=SON2cW8+G0GZeh91YocaLuB63u8O5deIrcfGm+v6Dso=;
	b=ZzHYj7xBQwohmc4scDmguzMHFd7IgEHwgEIEHBjlX5BDHDVQHIok0RtYIGxN3gg3ahK2cr
	VOeVk/nkjixLx9ImudKNA/UvZhKhoZoK6ZW9VbEUTPt6bg+PS3yK+KohNFvol3Rh9bBUd1
	sG2KGFY0NNXgTwzbKyBZ+FdvAC6ohAo=
Received: from mail-io1-f71.google.com (mail-io1-f71.google.com
 [209.85.166.71]) (Using TLS) by relay.mimecast.com with ESMTP id
 us-mta-470-t5ylhjnMPOStmlEKRlF3qw-1; Mon, 19 Apr 2021 06:00:50 -0400
X-MC-Unique: t5ylhjnMPOStmlEKRlF3qw-1
Received: by mail-io1-f71.google.com with SMTP id e9-20020a6b73090000b02903df1a776a08so9269276ioh.18
        for <dm-crypt@saout.de>; Mon, 19 Apr 2021 03:00:50 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20161025;
        h=x-gm-message-state:mime-version:from:date:message-id:subject:to;
        bh=SON2cW8+G0GZeh91YocaLuB63u8O5deIrcfGm+v6Dso=;
        b=JUkkRhRo8vIIHulZRuDNCFei3cBF9vBOVywYTEs9rAYlsMoCsTd4MbMYn9y/9gkrne
         vugreUMeOmTjwywwaH/8RkBp3fysgMmcnIlgIxxUQ0cp1nNyNjkMPFLKJ+llBuuY92qi
         zfGYJqcU9xbOYJ5OnTMUWAHsFvDbZOBVHiCxqqMI9nmOvoCtyNbzA0gWlR5yRj5kOFLq
         Q3BWlxW8s4G3c3nO3hvw1uxVsmG5S5RgCs8e95OMPWSteWi4G3W1FUpVtam2imf7zFHO
         CIe3hE5WBGDwJw4FKjyPz3JcUnZaNmHfgLwZ6CmjwVxnyU7LZ7076RfUMgUXC3MqUvXH
         cTQA==
X-Gm-Message-State: AOAM530szEsl6C/9YXh1rRsbuKSeD9Z3Jv1y+x0Yjv2VfYx5o/r0wBti
	H85izWpm+bUt2dB5FH3Zb6T5z3MDnJmrWf5tP3qwowfB2q0JbaJm1HK1TfakZOsbRWSZ8T+vuVX
	/8TPpgCkd4nxPD15JwJCNRmjoTA==
X-Received: by 2002:a92:6908:: with SMTP id e8mr17220337ilc.207.1618826449995;
        Mon, 19 Apr 2021 03:00:49 -0700 (PDT)
X-Google-Smtp-Source: ABdhPJxzhJdztyoLFo2YkadscmKue8No2qexBUliOtMqgptZ+IlCs4gY2gw+UYC+OUMKfuPGI2txOXPGAX3fDMoNEqM=
X-Received: by 2002:a92:6908:: with SMTP id e8mr17220312ilc.207.1618826449598;
 Mon, 19 Apr 2021 03:00:49 -0700 (PDT)
MIME-Version: 1.0
From: Kairui Song <kasong@redhat.com>
Date: Mon, 19 Apr 2021 18:00:38 +0800
Message-ID: <CACPcB9e0=KYNc_-Bz5EnoHntKKXpurmXzu4e60J1sADQkizvsg@mail.gmail.com>
To: systemd-devel@lists.freedesktop.org, dm-crypt@saout.de,
	Development discussions related to Fedora <devel@lists.fedoraproject.org>, kexec@lists.fedoraproject.org
Authentication-Results: relay.mimecast.com;
	auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=kasong@redhat.com
X-Mimecast-Spam-Score: 0
X-Mimecast-Originator: redhat.com
X-MailFrom: kasong@redhat.com
X-Mailman-Rule-Hits: nonmember-moderation
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-dm-crypt.saout.de-0
Message-ID-Hash: QO5EHBVTYC4D64PJEWHTII3VLHANG442
X-Message-ID-Hash: QO5EHBVTYC4D64PJEWHTII3VLHANG442
X-Mailman-Approved-At: Mon, 19 Apr 2021 20:14:59 +0200
X-Mailman-Version: 3.3.2
Precedence: list
Subject: [dm-crypt] Kdump with full-disk LUKS encryption
List-Id: <dm-crypt.saout.de>
List-Help: <mailto:dm-crypt-request@saout.de?subject=help>
List-Post: <mailto:dm-crypt@saout.de>
List-Subscribe: <mailto:dm-crypt-join@saout.de>
List-Unsubscribe: <mailto:dm-crypt-leave@saout.de>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit

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).

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.

But LUKS2/cryptsetup now stores the key in the kernel keyring by
default. The key is accessible from userspace.

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.org/thread/RTYJEQ4BV25JYVYJHTTPOK476FUEJOWW/)

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.

2. If we can let the key stay in userspace for a little longer, eg.
for systems booted with dracut/systemd, when
systemd-cryptsetup@%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.

3. Let kdump use some custom helper/service to load all needed
resources in the early initrd boot stage, prior to
systemd-cryptsetup@%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.

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.

Any suggestions are welcomed!

--
Best Regards,
Kairui Song

_______________________________________________
dm-crypt mailing list -- dm-crypt@saout.de
To unsubscribe send an email to dm-crypt-leave@saout.de