Re: [PATCH v10 6/8] ima: kexec: move IMA log copy from kexec load to execute

From: Baoquan He
Date: Tue Mar 25 2025 - 22:28:28 EST


On 03/25/25 at 03:27pm, steven chen wrote:
> On 3/24/2025 4:00 AM, Baoquan He wrote:
> > On 03/21/25 at 09:23am, steven chen wrote:
> > > On 3/19/2025 7:06 PM, Baoquan He wrote:
> > > > On 03/17/25 at 06:04pm, steven chen wrote:
> > > > ...snip...
> > > > > ---
> > > > > kernel/kexec_file.c | 10 ++++++
> > > > > security/integrity/ima/ima_kexec.c | 51 ++++++++++++++++++------------
> > > > > 2 files changed, 40 insertions(+), 21 deletions(-)
> > > > >
> > > > > diff --git a/kernel/kexec_file.c b/kernel/kexec_file.c
> > > > > index 606132253c79..ab449b43aaee 100644
> > > > > --- a/kernel/kexec_file.c
> > > > > +++ b/kernel/kexec_file.c
> > > > > @@ -201,6 +201,13 @@ kimage_validate_signature(struct kimage *image)
> > > > > }
> > > > > #endif
> > > > > +static void kimage_file_post_load(struct kimage *image)
> > > > > +{
> > > > > +#ifdef CONFIG_IMA_KEXEC
> > > > > + ima_kexec_post_load(image);
> > > > > +#endif
> > > > > +}
> > > > > +
> > > > > /*
> > > > > * In file mode list of segments is prepared by kernel. Copy relevant
> > > > > * data from user space, do error checking, prepare segment list
> > > > > @@ -428,6 +435,9 @@ SYSCALL_DEFINE5(kexec_file_load, int, kernel_fd, int, initrd_fd,
> > > > > kimage_terminate(image);
> > > > > + if (!(flags & KEXEC_FILE_ON_CRASH))
> > > > > + kimage_file_post_load(image);
> > > > machine_kexec_post_load() is called by both kexec_load and kexec_file_load,
> > > > we should use it to do things post load, but not introducing another
> > > > kimage_file_post_load().
> > > Hi Baoquan,
> > >
> > > Could you give me more detail about this?
> > I mean machine_kexec_post_load() is the place where post load operations
> > are done, including kexec_load and kexec_file_load. There's no need to
> > specifically introduce a kimage_file_post_load() to do post load
> > operaton for kexec_file_load.
>
> Hi Baoquan,
>
> Updating the machine_kexec_post_load() API to carry flags would indeed
> require changes to multiple files. This approach involves the condition
> check if (!(flags & KEXEC_FILE_ON_CRASH)) and ensuring that the flags are
> properly passed and handled across the relevant file
>
> if just adding a API kimage_file_post_load() here, it is much easy and
> clean, right?

Hmm, it's easier, while maybe not good. We should not repeatedly
introduce similar things into codes. Here, it's similar as
what kexec_apply_relocations() and arch_kexec_apply_relocations() are
doing.

int machine_kexec_post_load(struct kimage *image)
{
#ifdef CONFIG_IMA_KEXEC
ima_kexec_post_load(image);
#endif
return arch_machine_kexec_post_load();
}

Then a generic arch_machine_kexec_post_load(struct kimage *image)
{return 0;} version, and a arm64 specific version.

Is it OK to you?