On 1/11/24 13:13, Tushar Sugandhi wrote:
On 1/7/24 09:00, Mimi Zohar wrote:
On Fri, 2024-01-05 at 12:20 -0800, Tushar Sugandhi wrote:
diff --git a/security/integrity/ima/Kconfig
b/security/integrity/ima/Kconfig
index 60a511c6b583..8792b7aab768 100644
--- a/security/integrity/ima/Kconfig
+++ b/security/integrity/ima/Kconfig
@@ -338,3 +338,12 @@ 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 64
Since this isn't optional, the default should remain as a half page.
Since a page is architecture specific, the default will need to be arch
specific
It was a feedback from Stefan in the V2 of this series to convert it
from number of PAGES to KB.[1]
But I can revert it to number of pages again.
Also, making the default value as a fraction (1/2 page) feels weird for
a CONFIG variable.
Is it ok to make the default value as one page rather than half page?
The point is not whether the extra memory is specified in terms of
pages or KB.
For backwards compatibility the existing default should be the same as
previously. This means the default needs to be architecture specific.b
$ uname -m; getconf PAGESIZE
x86_64
4096
$ uname -m; getconf PAGESIZE
ppc64le
65536
For example:
default 32 if PPC_64K_PAGES
default 2
Ok. Thanks for the clarification.
Do we want to support only 64K or 4K as possible PAGE_SIZE values?
I spot checked a few architectures, there are scenarios where PAGE_SIZE
could be 8K, 16K, 128K, 256K etc. And of course mega pages with
PAGE_SIZE IN MBs (details below).
I would let the user specify the number of kilobytes to reserve and from
this you can conclude the page numbers:
needed_pages = KBs_TO_RESERVE / PAGE_SIZE
if (KBs_TO_RESERVER % PAGE_SIZE)
needed_pages++;
Stefan
_______________________________________________
kexec mailing list
kexec@xxxxxxxxxxxxxxxxxxx
http://lists.infradead.org/mailman/listinfo/kexec
