[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <6583378c-55ee-4192-a95f-ebaf3f708bbb@linux.microsoft.com>
Date: Tue, 25 Mar 2025 15:27:44 -0700
From: steven chen <chenste@...ux.microsoft.com>
To: Baoquan He <bhe@...hat.com>
Cc: zohar@...ux.ibm.com, stefanb@...ux.ibm.com,
roberto.sassu@...weicloud.com, roberto.sassu@...wei.com,
eric.snowberg@...cle.com, ebiederm@...ssion.com, paul@...l-moore.com,
code@...icks.com, bauermann@...abnow.com, linux-integrity@...r.kernel.org,
kexec@...ts.infradead.org, linux-security-module@...r.kernel.org,
linux-kernel@...r.kernel.org, madvenka@...ux.microsoft.com,
nramas@...ux.microsoft.com, James.Bottomley@...senpartnership.com,
vgoyal@...hat.com, dyoung@...hat.com
Subject: Re: [PATCH v10 6/8] ima: kexec: move IMA log copy from kexec load to
execute
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?
How do you think?
Thanks,
Steven
Powered by blists - more mailing lists