Received: by 2002:ab2:784b:0:b0:1fd:adc2:8405 with SMTP id m11csp99538lqp; Sun, 9 Jun 2024 19:00:23 -0700 (PDT) X-Forwarded-Encrypted: i=3; AJvYcCWE2/R5dM9ahosu4SuPJFRvuvUzAERdOHilnnW4A0c+Fn3piRXSSDk6p2oHr3zcMNZICoLEyVzhLQ9pp4lKsFMcMrr6g3Gs/wgD2j6img== X-Google-Smtp-Source: AGHT+IHi7xzXBqUgKa8PqU2s4IeFZdtNTw0cpOE0wVmZx6GJTeYSHsCkU3nbUNKC1NSkn6dY/PEv X-Received: by 2002:a05:622a:1108:b0:43f:fa1e:c8e5 with SMTP id d75a77b69052e-4403621ffe1mr216460561cf.8.1717984822913; Sun, 09 Jun 2024 19:00:22 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1717984822; cv=pass; d=google.com; s=arc-20160816; b=SPFaWne/HnOI5VeBYhnKQ+EX040450D2028mbtshKoGNqSxJ1tKVSwsDnn3khUB5pU zov912mEIqB+Z/VCLKgja+ixOi6vTmEs2dnLz46q/i3lQNFsFX3+8WnpPlnbLBorbFUi Pf9ryC6QsuH+FFEYMKeI0eryz0mfqkNix5cOx3395oVqEPyteinjj4QWNLJhvXfD0gtR mva7m6d+hXrBPby2EK2i7mpDduAsSYyw3ATSVRX32r9yUyUyIyyA1HoLOCwCcYF+xlI+ F8W5E9KfxzrztmmkEoQrn6BE5KtKzx5akghgPY0o4A4oxzlzJtx8Kjk1oLMLDqn4EA9l nxnQ== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=in-reply-to:content-disposition:mime-version:list-unsubscribe :list-subscribe:list-id:precedence:references:message-id:subject:cc :to:from:date:dkim-signature; bh=aOO4GVvcO0xxLYThv3Qu7QqLhlBUXRK/6CUBfcNRt6Y=; fh=j9nnfeBvIx3g2V21SGRFxMM4l/cnXxo00zKmU7KDkrE=; b=xVCZbebmJh3h2QgCaqDwmC7mOPKEbqzaq95n0uOmoxzJFMGJx7abztYhCrD2ODMn3U 2DiIHPyIg7b/Uknz2mAkmtiDr/97DKh0cXeNW75LxX4x9JDQNbWIjamJULmaUPy2oUGa 6TY4+MxHewouB5iJK9t31/mGe5YCHfJWI/T/n+HAqDiwn/pBj/SCYzZVTKHYqI8RE/uR NvV7f8Snmoguxd65RWhpEjXKKUaPJQ7HvMGZ+SxiBcivD0Furiq/nuau7IKYtQgj1swp sY18kpW3YcJHnkI8mGyuEX+BwAER9SCf2GJPmQhOaUcAxkATSIrAfe435q6JbzVPKQZt KFRQ==; dara=google.com ARC-Authentication-Results: i=2; mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=LGy2wb64; arc=pass (i=1 spf=pass spfdomain=redhat.com dkim=pass dkdomain=redhat.com dmarc=pass fromdomain=redhat.com); spf=pass (google.com: domain of linux-kernel+bounces-207588-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.199.223 as permitted sender) smtp.mailfrom="linux-kernel+bounces-207588-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from ny.mirrors.kernel.org (ny.mirrors.kernel.org. [147.75.199.223]) by mx.google.com with ESMTPS id d75a77b69052e-440521b97bbsi55779201cf.804.2024.06.09.19.00.22 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 09 Jun 2024 19:00:22 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel+bounces-207588-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.199.223 as permitted sender) client-ip=147.75.199.223; Authentication-Results: mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=LGy2wb64; arc=pass (i=1 spf=pass spfdomain=redhat.com dkim=pass dkdomain=redhat.com dmarc=pass fromdomain=redhat.com); spf=pass (google.com: domain of linux-kernel+bounces-207588-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.199.223 as permitted sender) smtp.mailfrom="linux-kernel+bounces-207588-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ny.mirrors.kernel.org (Postfix) with ESMTPS id 9042D1C20C6A for ; Mon, 10 Jun 2024 02:00:22 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 0D4304A2F; Mon, 10 Jun 2024 02:00:18 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="LGy2wb64" Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 2ADA61C3E for ; Mon, 10 Jun 2024 02:00:14 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=170.10.129.124 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1717984817; cv=none; b=N52RdALk60bDVuG0Tz8NBwHY47C/GDsg2fStWfARA9DeyS8h/vbFGn52XlZxFlDfvKddRQwNtBMDugcdhPYslCyfbz2Xsdc/3ETZ6MG1znv/vmLTBQEsBC0sB7AmMBfRZslypzUQhtfBgeldm8jNaCaOm2p1wI6+un7XPGY83mI= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1717984817; c=relaxed/simple; bh=SXB30ZzUlkp5H3QAvEGmgh4pmYdO5hRaa1DkR4J7vMk=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=gF0WccUXgA9bi1ZDgJ194X/aO9BvSU+H+/f1rxuzGy0jY7rJ6k+F5ecNfbQgA5KjLMrh3j7MwwHP3cz1MSBp4yxO0+qGNJYoi41bVxbrMToVo4wNbBmqQwwltWz0sUTdeo58ITh1/q5LibQKYAgwFDndwpEDo4Fu/OAdJFAatFA= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=redhat.com; spf=pass smtp.mailfrom=redhat.com; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b=LGy2wb64; arc=none smtp.client-ip=170.10.129.124 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=redhat.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1717984814; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=aOO4GVvcO0xxLYThv3Qu7QqLhlBUXRK/6CUBfcNRt6Y=; b=LGy2wb64h1F78ziEBLYogCwV4Bf9o6pr8jRJ4UiF7IEhzAjTbLNQH3I68oV6RyMwYuQfbf eT4t8802JECYwEPLo96VHxTMPk7dPBHyPv9JFytgiw/0b9HbK04xKVr0oLpqteHDOLQEP+ RNos7VFur3ULf67CMtyijLzbHmcY2ew= Received: from mimecast-mx02.redhat.com (mimecast-mx02.redhat.com [66.187.233.88]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-371-YTJnEZSHN1GUcLYIlQdWmg-1; Sun, 09 Jun 2024 22:00:10 -0400 X-MC-Unique: YTJnEZSHN1GUcLYIlQdWmg-1 Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.rdu2.redhat.com [10.11.54.5]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id D2CC085A5B5; Mon, 10 Jun 2024 02:00:09 +0000 (UTC) Received: from localhost (unknown [10.72.113.124]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 97CCF175ED; Mon, 10 Jun 2024 02:00:07 +0000 (UTC) Date: Mon, 10 Jun 2024 10:00:05 +0800 From: Baoquan He To: Coiby Xu Cc: kexec@lists.infradead.org, Ondrej Kozina , Milan Broz , Thomas Staudt , Daniel P =?iso-8859-1?Q?=2E_Berrang=E9?= , Kairui Song , Jan Pazdziora , Pingfan Liu , Dave Young , linux-kernel@vger.kernel.org, x86@kernel.org, Dave Hansen , Vitaly Kuznetsov , Vivek Goyal , Kees Cook , "Gustavo A. R. Silva" , "open list:KERNEL HARDENING (not covered by other areas):Keyword:b__counted_byb" Subject: Re: [PATCH v4 2/7] crash_dump: make dm crypt keys persist for the kdump kernel Message-ID: References: <20240523050451.788754-1-coxu@redhat.com> <20240523050451.788754-3-coxu@redhat.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Scanned-By: MIMEDefang 3.4.1 on 10.11.54.5 On 06/07/24 at 08:27pm, Coiby Xu wrote: > On Tue, Jun 04, 2024 at 04:51:03PM +0800, Baoquan He wrote: > > Hi Coiby, > > Hi Baoquan, > > > > > On 05/23/24 at 01:04pm, Coiby Xu wrote: > > > A sysfs /sys/kernel/crash_dm_crypt_keys is provided for user space to make > > > the dm crypt keys persist for the kdump kernel. User space can send the > > > following commands, > > > - "init KEY_NUM" > > > Initialize needed structures > > > - "record KEY_DESC" > > > Record a key description. The key must be a logon key. > > > > > > User space can also read this API to learn about current state. > > > > From the subject, can I think the luks keys will persist forever? or > > only for a while? > > Yes, you are right. The keys need to stay in kdump reserved memory. Hmm, there are two different concepts we may need differentiate. From security keys's point of view, the keys need be stored for a while so that kdump loading take action to get it, that's done through sysfs; Froom kdump's point of view, the keys need be stored forever till kdump kernel use it. I can't see what you are referring to from the subject, esepcially you stress the newly added sysfs /sys/kernel/crash_dm_crypt_keys. > > > If need and can only keep it for a while, can you > > mention it and tell why and how it will be used. Because you add a lot > > of codes, but only simply mention the sysfs, that doesn't make sense. > > Thanks for raising the concern! I've added > Documentation/ABI/testing/crash_dm_crypt_keys and copy some text in the > cover letter to this patch in v5. > > > > > > > > > Signed-off-by: Coiby Xu > > > --- > > > include/linux/crash_core.h | 5 +- > > > kernel/Kconfig.kexec | 8 +++ > > > kernel/Makefile | 1 + > > > kernel/crash_dump_dm_crypt.c | 113 +++++++++++++++++++++++++++++++++++ > > > kernel/ksysfs.c | 22 +++++++ > > > 5 files changed, 148 insertions(+), 1 deletion(-) > > > create mode 100644 kernel/crash_dump_dm_crypt.c > > > > > > diff --git a/include/linux/crash_core.h b/include/linux/crash_core.h > > > index 44305336314e..6bff1c24efa3 100644 > > > --- a/include/linux/crash_core.h > > > +++ b/include/linux/crash_core.h > > > @@ -34,7 +34,10 @@ static inline void arch_kexec_protect_crashkres(void) { } > > > static inline void arch_kexec_unprotect_crashkres(void) { } > > > #endif > [...] > > > +static int init(const char *buf) > > ~~~~ A more interesting name with more description? > > Thanks for the suggestion! I've added some comments for this function > in v5. But I can't come up with a better name after looking at current > kernel code. You are welcome to suggest any better name:) Usually init() is for the whole driver module. Your init() here only receive the passed total keys number, and allocate the key_header, how can you simply name it init()? If you call it init_keys_header(), I would think it's much more meaningful. > > > > +static int process_cmd(const char *buf, size_t count) > > ~~~~ > > If nobody use the count, why do you add it? > > Good catch! Yes, this is no need to use count in v4. But v5 now needs it to avoid > buffer overflow. OK, did you add code comment telling what 'count' stands for? And the name 'process_cmd()' is also ambiguous. We may need avoid this kind of name, e.g process_cmd, do_things, handle_stuff. Can you add a more specific name?