Kexec Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Baoquan He <bhe@redhat.com>
To: "Eric W. Biederman" <ebiederm@xmission.com>,
	Sourabh Jain <sourabhjain@linux.ibm.com>
Cc: Petr Tesarik <petr.tesarik@suse.com>,
	Hari Bathini <hbathini@linux.ibm.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	Eric DeVolder <eric.devolder@oracle.com>,
	"open list:KEXEC" <kexec@lists.infradead.org>,
	open list <linux-kernel@vger.kernel.org>,
	Petr Tesarik <ptesarik@suse.com>,
	stable@kernel.org
Subject: Re: [PATCH 1/1] kexec_file: fix elfcorehdr digest exclusion when CONFIG_CRASH_HOTPLUG=y
Date: Thu, 12 Sep 2024 17:54:43 +0800	[thread overview]
Message-ID: <ZuK6Y1+Z5x4Hvt4P@MiWiFi-R3L-srv> (raw)
In-Reply-To: <871q2oy6eb.fsf@email.froward.int.ebiederm.org>

Hi Eric,

On 08/16/24 at 07:54am, Eric W. Biederman wrote:
> Petr Tesarik <petr.tesarik@suse.com> writes:
> 
> > From: Petr Tesarik <ptesarik@suse.com>
> >
> > Fix the condition to exclude the elfcorehdr segment from the SHA digest
> > calculation.
> >
> > The j iterator is an index into the output sha_regions[] array, not into
> > the input image->segment[] array. Once it reaches image->elfcorehdr_index,
> > all subsequent segments are excluded. Besides, if the purgatory segment
> > precedes the elfcorehdr segment, the elfcorehdr may be wrongly included in
> > the calculation.
> 
> I would rather make CONFIG_CRASH_HOTPLUG depend on broken.
> 
> The hash is supposed to include everything we depend upon so when
> a borken machine corrupts something we can detect that corruption
> and not attempt to take a crash dump.
> 
> The elfcorehdr is definitely something that needs to be part of the
> hash.
> 
> So please go back to the drawing board and find a way to include the
> program header in the hash even with CONFIG_CRASH_HOTPLUG.

Thanks for checking this and adding your advice, and sorry for late
reply.

It's me who suggested Eric DeVolder not adding elfcorehdr into kdump
kernel iamge hash during reviewing his patch. I need explain this if
people has concern. When I suggested this, what I considered are:

1) The code change will be much simpler. As you can see, later Eric
   DeVolder's patchset experienced rounds of reviewing and finally
   merged. Below is his final round:

   - [PATCH v28 0/8] crash: Kernel handling of CPU and memory hot un/plug

2) The efficiency will be improved very much relative to adding
   elfcorehdr to the entire hash. When cpu/mem hotplug triggered,
   we only touch elfcorehdr area, but don't need access the entire
   loading segments.

3) The elfcorehdr size is very tiny relative to kernel image and initrd.
   E.g on x86, it's less than 1M, which is tiny relative to dozens of 
   kernel image and initrd.

Surely, adding all loading segments into hash is the best. While
attracted by above benefits, I tend to not add for the time being. I am
open to this, if anyone has concern about the security and is interested
in the adding as a kernel project practice in the future, it's welcomed.

Here I'd like to request comment from Sourabh since he and other IBM dev 
added the support to ppc too. Different than generic ARCH, IBM dev can
be seen as a end user, maybe we can hear how they evaluate the balance
between the risk and benefit.

Thanks
Baoquan


_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

      parent reply	other threads:[~2024-09-12  9:55 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-08-05 15:07 [PATCH 1/1] kexec_file: fix elfcorehdr digest exclusion when CONFIG_CRASH_HOTPLUG=y Petr Tesarik
2024-08-05 15:17 ` Petr Tesarik
2024-08-05 22:59 ` Baoquan He
2024-08-16  6:33   ` Petr Tesarik
2024-08-16  7:12 ` Baoquan He
2024-08-16 12:54 ` Eric W. Biederman
2024-08-16 13:42   ` Petr Tesarik
2024-09-12  9:54   ` Baoquan He [this message]

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=ZuK6Y1+Z5x4Hvt4P@MiWiFi-R3L-srv \
    --to=bhe@redhat.com \
    --cc=akpm@linux-foundation.org \
    --cc=ebiederm@xmission.com \
    --cc=eric.devolder@oracle.com \
    --cc=hbathini@linux.ibm.com \
    --cc=kexec@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=petr.tesarik@suse.com \
    --cc=ptesarik@suse.com \
    --cc=sourabhjain@linux.ibm.com \
    --cc=stable@kernel.org \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox