From: Stefan Berger <stefanb@linux.ibm.com>
To: Tushar Sugandhi <tusharsu@linux.microsoft.com>,
zohar@linux.ibm.com, roberto.sassu@huaweicloud.com,
roberto.sassu@huawei.com, eric.snowberg@oracle.com,
ebiederm@xmission.com, noodles@fb.com, bauermann@kolabnow.com,
linux-integrity@vger.kernel.org, kexec@lists.infradead.org
Cc: code@tyhicks.com, nramas@linux.microsoft.com, paul@paul-moore.com
Subject: Re: [PATCH v4 6/7] ima: make the kexec extra memory configurable
Date: Tue, 23 Jan 2024 14:02:52 -0500 [thread overview]
Message-ID: <bdf8c31a-59db-4568-ad7b-e2b3f36c3836@linux.ibm.com> (raw)
In-Reply-To: <20240122183804.3293904-7-tusharsu@linux.microsoft.com>
On 1/22/24 13:38, Tushar Sugandhi wrote:
> The extra memory allocated for carrying the IMA measurement list across
> kexec is hardcoded as half a PAGE. Make it configurable.
>
> Define a Kconfig option, IMA_KEXEC_EXTRA_MEMORY_KB, to configure the
> extra memory (in kb) to be allocated for IMA measurements added during
> kexec soft reboot. Ensure the default value of the option is set such
> that extra half a page of memory for additional measurements is allocated
> to maintain backwards compatibility.
>
> Update ima_add_kexec_buffer() function to allocate memory based on the
> Kconfig option value, rather than the currently hardcoded one.
>
> Signed-off-by: Tushar Sugandhi <tusharsu@linux.microsoft.com>
> ---
> security/integrity/ima/Kconfig | 11 +++++++++++
> security/integrity/ima/ima_kexec.c | 15 ++++++++++-----
> 2 files changed, 21 insertions(+), 5 deletions(-)
>
> diff --git a/security/integrity/ima/Kconfig b/security/integrity/ima/Kconfig
> index 60a511c6b583..fc103288852b 100644
> --- a/security/integrity/ima/Kconfig
> +++ b/security/integrity/ima/Kconfig
> @@ -338,3 +338,14 @@ config IMA_DISABLE_HTABLE
> default n
> help
> This option disables htable to allow measurement of duplicate records.
> +
> +config IMA_KEXEC_EXTRA_MEMORY_KB
> + int
> + depends on IMA && IMA_KEXEC
> + default 0
> + help
> + IMA_KEXEC_EXTRA_MEMORY_KB determines the extra memory to be
> + allocated (in kb) for IMA measurements added during kexec soft reboot.
> + If set to the default value, an extra half page of memory for
> + additional measurements will be allocated to maintain backwards
> + compatibility.
Is there really an issue with 'backwards compatibility' that the user
needs to know about ? From looking at the code it seems more important
that a bit of additional memory is reserved now to fit the kexec 'load'
and 'exec' critical data events but that's not 'backwards compatibility'.
Also mention this as a guidance on either how kexec load+exec need to be
used or as a hint that it may potentially require a lot of memory? :
The amount of extra memory that is necessary to carry all measurements
across a kexec depends on memory requirements of the measurements taken
between the kexec 'load' and 'exec' stages. The more measurements are
taken, the more extra memory is required. Large amounts of extra memory
can be avoided by running kexec 'load' and 'exec' in short sequence.
> diff --git a/security/integrity/ima/ima_kexec.c b/security/integrity/ima/ima_kexec.c
> index f26b5b342d84..c126aa6494e9 100644
> --- a/security/integrity/ima/ima_kexec.c
> +++ b/security/integrity/ima/ima_kexec.c
> @@ -121,6 +121,7 @@ void ima_add_kexec_buffer(struct kimage *image)
> .buf_min = 0, .buf_max = ULONG_MAX,
> .top_down = true };
> unsigned long binary_runtime_size;
> + unsigned long extra_size;
>
> /* use more understandable variable names than defined in kbuf */
> void *kexec_buffer = NULL;
> @@ -128,15 +129,19 @@ void ima_add_kexec_buffer(struct kimage *image)
> int ret;
>
> /*
> - * Reserve an extra half page of memory for additional measurements
> - * added during the kexec load.
> + * Reserve extra memory for measurements added during kexec.
> */
> - binary_runtime_size = ima_get_binary_runtime_size();
> + if (CONFIG_IMA_KEXEC_EXTRA_MEMORY_KB <= 0)
> + extra_size = PAGE_SIZE / 2;
> + else
> + extra_size = CONFIG_IMA_KEXEC_EXTRA_MEMORY_KB * 1024;
> + binary_runtime_size = ima_get_binary_runtime_size() + extra_size;
> +
> if (binary_runtime_size >= ULONG_MAX - PAGE_SIZE)
> kexec_segment_size = ULONG_MAX;
> else
> - kexec_segment_size = ALIGN(ima_get_binary_runtime_size() +
> - PAGE_SIZE / 2, PAGE_SIZE);
> + kexec_segment_size = ALIGN(binary_runtime_size, PAGE_SIZE);
> +
> if ((kexec_segment_size == ULONG_MAX) ||
> ((kexec_segment_size >> PAGE_SHIFT) > totalram_pages() / 2)) {
> pr_err("Binary measurement list too large.\n");
Code LGTM
next prev parent reply other threads:[~2024-01-23 19:03 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-01-22 18:37 [PATCH v4 0/7] ima: kexec: measure events between kexec load and execute Tushar Sugandhi
2024-01-22 18:37 ` [PATCH v4 1/7] ima: define and call ima_alloc_kexec_file_buf Tushar Sugandhi
2024-01-24 2:54 ` Stefan Berger
2024-01-24 3:38 ` Stefan Berger
2024-01-26 22:14 ` Tushar Sugandhi
2024-01-24 13:33 ` Mimi Zohar
2024-01-25 19:03 ` Tushar Sugandhi
2024-01-22 18:37 ` [PATCH v4 2/7] kexec: define functions to map and unmap segments Tushar Sugandhi
2024-01-23 17:03 ` Stefan Berger
2024-01-23 20:39 ` Tushar Sugandhi
2024-01-22 18:38 ` [PATCH v4 3/7] ima: kexec: skip IMA segment validation after kexec soft reboot Tushar Sugandhi
2024-01-22 18:38 ` [PATCH v4 4/7] ima: kexec: move ima log copy from kexec load to execute Tushar Sugandhi
2024-01-24 16:11 ` Mimi Zohar
2024-01-25 19:06 ` Tushar Sugandhi
2024-01-22 18:38 ` [PATCH v4 5/7] ima: suspend measurements during buffer copy at kexec execute Tushar Sugandhi
2024-01-23 18:18 ` Stefan Berger
2024-01-23 20:55 ` Tushar Sugandhi
2024-01-22 18:38 ` [PATCH v4 6/7] ima: make the kexec extra memory configurable Tushar Sugandhi
2024-01-23 19:02 ` Stefan Berger [this message]
2024-01-23 21:19 ` Tushar Sugandhi
2024-01-24 1:48 ` Stefan Berger
2024-01-24 14:07 ` Mimi Zohar
2024-01-25 19:14 ` Tushar Sugandhi
2024-01-22 18:38 ` [PATCH v4 7/7] ima: measure kexec load and exec events as critical data Tushar Sugandhi
2024-01-24 14:35 ` Mimi Zohar
2024-01-25 19:16 ` 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=bdf8c31a-59db-4568-ad7b-e2b3f36c3836@linux.ibm.com \
--to=stefanb@linux.ibm.com \
--cc=bauermann@kolabnow.com \
--cc=code@tyhicks.com \
--cc=ebiederm@xmission.com \
--cc=eric.snowberg@oracle.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=roberto.sassu@huawei.com \
--cc=roberto.sassu@huaweicloud.com \
--cc=tusharsu@linux.microsoft.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