From: Tushar Sugandhi <tusharsu@linux.microsoft.com>
To: Mimi Zohar <zohar@linux.ibm.com>,
ebiederm@xmission.com, noodles@fb.com, bauermann@kolabnow.com,
kexec@lists.infradead.org, linux-integrity@vger.kernel.org
Cc: code@tyhicks.com, nramas@linux.microsoft.com, paul@paul-moore.com
Subject: Re: [PATCH v2 2/7] ima: move ima_dump_measurement_list call from kexec load to execute
Date: Tue, 14 Nov 2023 14:43:58 -0800 [thread overview]
Message-ID: <57c97b4f-8489-4cac-8014-c16e4af8fcfc@linux.microsoft.com> (raw)
In-Reply-To: <989af3e9a8621f57643b67b717d9a39fdb2ffe24.camel@linux.ibm.com>
On 10/27/23 06:08, Mimi Zohar wrote:
> Hi Tushar,
>
> On Thu, 2023-10-05 at 11:25 -0700, Tushar Sugandhi wrote:
>> In the current IMA implementation, ima_dump_measurement_list() is called
>> during the kexec 'load' operation. This can result in loss of IMA
>> measurements taken between the 'load' and 'execute' phases when the
>> system goes through Kexec soft reboot to a new Kernel. The call to the
>> function ima_dump_measurement_list() needs to be moved out of the
>> function ima_add_kexec_buffer() and needs to be called during the kexec
>> 'execute' operation.
>>
>> Implement a function ima_update_kexec_buffer() that is called during
>> kexec 'execute', allowing IMA to update the measurement list with the
>> events between kexec 'load' and 'execute'. Move the
>> ima_dump_measurement_list() call from ima_add_kexec_buffer() to
>> ima_update_kexec_buffer(). Make ima_kexec_buffer and kexec_segment_size
>> variables global, so that they can be accessed during both kexec 'load'
>> and 'execute'. Add functions ima_measurements_suspend() and
>> ima_measurements_resume() to set and reset the 'suspend_ima_measurements'
>> variable respectively, to suspend/resume IMA measurements. Use
>> the existing 'ima_extend_list_mutex' to ensure that the operations are
>> thread-safe. These function calls will help maintaining the integrity
>> of the IMA log while it is being copied to the new Kernel's buffer.
>> Add a reboot notifier_block 'update_buffer_nb' to ensure
>> the function ima_update_kexec_buffer() gets called during kexec
>> soft-reboot.
>>
>> Signed-off-by: Tushar Sugandhi <tusharsu@linux.microsoft.com>
>
> The lengthiness and complexity of the patch description is an
> indication that the patch needs to be broken up. Please refer to
> Documentation/process/submitting-patches.rst for further info.
>
> In addition, this patch moves the function ima_dump_measurement_list()
> to a new function named ima_update_kexec_buffer(), which is never
> called. The patch set is thus not bisect safe.
> > [...]
>> +void ima_measurements_suspend(void)
>> +{
>> + mutex_lock(&ima_extend_list_mutex);
>> + atomic_set(&suspend_ima_measurements, 1);
>> + mutex_unlock(&ima_extend_list_mutex);
>> +}
>> +
>> +void ima_measurements_resume(void)
>> +{
>> + mutex_lock(&ima_extend_list_mutex);
>> + atomic_set(&suspend_ima_measurements, 0);
>> + mutex_unlock(&ima_extend_list_mutex);
>> +}
>
> These function are being defined and called here, but are not enforced
> until a later patch. It would make more sense to introduce and
> enforce these functions in a single patch with an explanation as to why
> suspend/resume is needed.
>
> The cover letter describes the problem as "... new IMA measurements are
> added between kexec 'load' and kexec 'execute'". Please include in
> the patch description the reason for needing suspend/resume, since
> saving the measurement records is done during kexec execute.
>
Since I am introducing a few new functions in this patch set,
I am having hard time keeping the patches bisect safe and at the same
time managing the length/complexity of the individual patches in the series.
I will go back and revisit the bisect-safeness of the patches in this
series again.
Thanks for the feedback, appreciate it.
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
next prev parent reply other threads:[~2023-11-14 22:44 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-10-05 18:25 [PATCH v2 0/7] ima: kexec: measure events between kexec load and execute Tushar Sugandhi
2023-10-05 18:25 ` [PATCH v2 1/7] ima: refactor ima_dump_measurement_list to move memory allocation to a separate function Tushar Sugandhi
2023-10-13 0:28 ` Stefan Berger
2023-10-20 20:33 ` Tushar Sugandhi
2023-10-20 21:21 ` Stefan Berger
2023-10-20 21:50 ` Tushar Sugandhi
2023-10-26 20:16 ` Mimi Zohar
2023-10-27 3:25 ` Mimi Zohar
2023-11-14 22:32 ` Tushar Sugandhi
2023-11-14 22:31 ` Tushar Sugandhi
2023-10-05 18:25 ` [PATCH v2 2/7] ima: move ima_dump_measurement_list call from kexec load to execute Tushar Sugandhi
2023-10-13 0:28 ` Stefan Berger
2023-10-20 20:35 ` Tushar Sugandhi
[not found] ` <989af3e9a8621f57643b67b717d9a39fdb2ffe24.camel@linux.ibm.com>
2023-11-14 22:43 ` Tushar Sugandhi [this message]
2023-11-15 22:30 ` Tushar Sugandhi
2023-10-05 18:25 ` [PATCH v2 3/7] ima: kexec: map source pages containing IMA buffer to image post kexec load Tushar Sugandhi
2023-10-13 0:29 ` Stefan Berger
2023-10-20 20:36 ` Tushar Sugandhi
2023-10-05 18:25 ` [PATCH v2 4/7] kexec: update kexec_file_load syscall to call ima_kexec_post_load Tushar Sugandhi
2023-10-05 18:26 ` [PATCH v2 5/7] ima: suspend measurements while the buffer is being copied during kexec reboot Tushar Sugandhi
2023-10-05 18:26 ` [PATCH v2 6/7] ima: make the memory for events between kexec load and exec configurable Tushar Sugandhi
2023-10-13 0:27 ` Stefan Berger
2023-10-20 20:39 ` Tushar Sugandhi
2023-10-20 21:16 ` Stefan Berger
2023-10-20 21:53 ` Tushar Sugandhi
2023-10-05 18:26 ` [PATCH v2 7/7] ima: record log size at kexec load and execute Tushar Sugandhi
2023-10-13 0:27 ` Stefan Berger
2023-10-20 20:40 ` Tushar Sugandhi
[not found] ` <2b95e8b9ebe10a24c7cb6fc90cb2d1342a157ed5.camel@linux.ibm.com>
2023-11-14 22:48 ` Tushar Sugandhi
[not found] ` <8f87e7e4fe5c5a24cdc0d3e2267eeaf00825d1bb.camel@linux.ibm.com>
2023-10-27 19:51 ` [PATCH v2 0/7] ima: kexec: measure events between " Mimi Zohar
2023-11-15 19:21 ` Tushar Sugandhi
2023-11-14 23:24 ` Tushar Sugandhi
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=57c97b4f-8489-4cac-8014-c16e4af8fcfc@linux.microsoft.com \
--to=tusharsu@linux.microsoft.com \
--cc=bauermann@kolabnow.com \
--cc=code@tyhicks.com \
--cc=ebiederm@xmission.com \
--cc=kexec@lists.infradead.org \
--cc=linux-integrity@vger.kernel.org \
--cc=noodles@fb.com \
--cc=nramas@linux.microsoft.com \
--cc=paul@paul-moore.com \
--cc=zohar@linux.ibm.com \
/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