From: steven chen <chenste@linux.microsoft.com>
To: zohar@linux.ibm.com, stefanb@linux.ibm.com,
roberto.sassu@huaweicloud.com, roberto.sassu@huawei.com,
eric.snowberg@oracle.com, ebiederm@xmission.com,
paul@paul-moore.com, code@tyhicks.com, bauermann@kolabnow.com,
linux-integrity@vger.kernel.org, kexec@lists.infradead.org,
linux-security-module@vger.kernel.org,
linux-kernel@vger.kernel.org
Cc: madvenka@linux.microsoft.com, nramas@linux.microsoft.com,
James.Bottomley@HansenPartnership.com, bhe@redhat.com,
vgoyal@redhat.com, dyoung@redhat.com
Subject: [PATCH v10 3/8] kexec: define functions to map and unmap segments
Date: Mon, 17 Mar 2025 18:04:41 -0700 [thread overview]
Message-ID: <20250318010448.954-4-chenste@linux.microsoft.com> (raw)
In-Reply-To: <20250318010448.954-1-chenste@linux.microsoft.com>
Currently, the kernel behavior during kexec load is to fetch the IMA
measurements log from TPM PCRs and store it in a buffer. When a kexec
reboot is triggered, this stored log buffer is carried over to the second
kernel. However, the time gap between kexec load and kexec reboot can be
very long. During this time window, new events extended into TPM PCRs miss
the chance to be carried over to the second kernel. This results in a
mismatch between TPM PCR quotes and the actual IMA measurements list after
kexec reboot, leading to remote attestation failure.
To solve this problem, the new design defers reading TPM PCRs content into
the kexec buffer to the kexec reboot phase, while still allocating the
necessary buffer at kexec load time because it is not appropriate to
allocate memory at the kexec reboot moment.
The content of memory segments carried over to the new kernel during the
kexec system call can be changed at the kexec 'execute' stage, but the size
of the memory segments cannot be changed at the kexec 'execute' stage.
To copy IMA measurement logs during the kexec operation, IMA allocates
memory at the kexec 'load' stage and map the segments to the kimage
structure. The mapped address will then be used to copy IMA measurements
during the kexec 'execute' stage.
Currently, the mechanism to map and unmap segments to the kimage structure
is not available to subsystems outside of kexec.
Implement kimage_map_segment() to enable IMA to map the measurement log
list to the kimage structure during the kexec 'load' stage. This function
takes a kimage pointer, a memory address, and a size, then gathers the
source pages within the specified address range, creates an array of page
pointers, and maps these to a contiguous virtual address range. The
function returns the start virtual address of this range if successful,
or NULL on failure.
Implement kimage_unmap_segment() for unmapping segments using vunmap().
From: Tushar Sugandhi <tusharsu@linux.microsoft.com>
Signed-off-by: Tushar Sugandhi <tusharsu@linux.microsoft.com>
Cc: Eric Biederman <ebiederm@xmission.com>
Cc: Baoquan He <bhe@redhat.com>
Cc: Vivek Goyal <vgoyal@redhat.com>
Cc: Dave Young <dyoung@redhat.com>
Signed-off-by: steven chen <chenste@linux.microsoft.com>
---
include/linux/kexec.h | 6 +++++
kernel/kexec_core.c | 54 +++++++++++++++++++++++++++++++++++++++++++
2 files changed, 60 insertions(+)
diff --git a/include/linux/kexec.h b/include/linux/kexec.h
index f0e9f8eda7a3..7d6b12f8b8d0 100644
--- a/include/linux/kexec.h
+++ b/include/linux/kexec.h
@@ -467,13 +467,19 @@ extern bool kexec_file_dbg_print;
#define kexec_dprintk(fmt, arg...) \
do { if (kexec_file_dbg_print) pr_info(fmt, ##arg); } while (0)
+extern void *kimage_map_segment(struct kimage *image, unsigned long addr, unsigned long size);
+extern void kimage_unmap_segment(void *buffer);
#else /* !CONFIG_KEXEC_CORE */
struct pt_regs;
struct task_struct;
+struct kimage;
static inline void __crash_kexec(struct pt_regs *regs) { }
static inline void crash_kexec(struct pt_regs *regs) { }
static inline int kexec_should_crash(struct task_struct *p) { return 0; }
static inline int kexec_crash_loaded(void) { return 0; }
+static inline void *kimage_map_segment(struct kimage *image, unsigned long addr, unsigned long size)
+{ return NULL; }
+static inline void kimage_unmap_segment(void *buffer) { }
#define kexec_in_progress false
#endif /* CONFIG_KEXEC_CORE */
diff --git a/kernel/kexec_core.c b/kernel/kexec_core.c
index c0bdc1686154..a5e378e1dc7f 100644
--- a/kernel/kexec_core.c
+++ b/kernel/kexec_core.c
@@ -867,6 +867,60 @@ int kimage_load_segment(struct kimage *image,
return result;
}
+void *kimage_map_segment(struct kimage *image,
+ unsigned long addr, unsigned long size)
+{
+ unsigned long src_page_addr, dest_page_addr = 0;
+ unsigned long eaddr = addr + size;
+ kimage_entry_t *ptr, entry;
+ struct page **src_pages;
+ unsigned int npages;
+ void *vaddr = NULL;
+ int i;
+
+ /*
+ * Collect the source pages and map them in a contiguous VA range.
+ */
+ npages = PFN_UP(eaddr) - PFN_DOWN(addr);
+ src_pages = kmalloc_array(npages, sizeof(*src_pages), GFP_KERNEL);
+ if (!src_pages) {
+ pr_err("Could not allocate ima pages array.\n");
+ return NULL;
+ }
+
+ i = 0;
+ for_each_kimage_entry(image, ptr, entry) {
+ if (entry & IND_DESTINATION) {
+ dest_page_addr = entry & PAGE_MASK;
+ } else if (entry & IND_SOURCE) {
+ if (dest_page_addr >= addr && dest_page_addr < eaddr) {
+ src_page_addr = entry & PAGE_MASK;
+ src_pages[i++] =
+ virt_to_page(__va(src_page_addr));
+ if (i == npages)
+ break;
+ dest_page_addr += PAGE_SIZE;
+ }
+ }
+ }
+
+ /* Sanity check. */
+ WARN_ON(i < npages);
+
+ vaddr = vmap(src_pages, npages, VM_MAP, PAGE_KERNEL);
+ kfree(src_pages);
+
+ if (!vaddr)
+ pr_err("Could not map ima buffer.\n");
+
+ return vaddr;
+}
+
+void kimage_unmap_segment(void *segment_buffer)
+{
+ vunmap(segment_buffer);
+}
+
struct kexec_load_limit {
/* Mutex protects the limit count. */
struct mutex mutex;
--
2.25.1
next prev parent reply other threads:[~2025-03-18 1:05 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-03-18 1:04 [PATCH v10 0/8] ima: kexec: measure events between kexec load and execute steven chen
2025-03-18 1:04 ` [PATCH v10 1/8] ima: rename variable the ser_file "file" to "ima_kexec_file" steven chen
2025-03-18 15:10 ` Stefan Berger
2025-03-19 2:43 ` Baoquan He
2025-03-21 16:15 ` steven chen
2025-03-19 13:42 ` Mimi Zohar
2025-03-21 16:16 ` steven chen
2025-03-18 1:04 ` [PATCH v10 2/8] ima: define and call ima_alloc_kexec_file_buf() steven chen
2025-03-19 8:09 ` Baoquan He
2025-03-19 16:27 ` Mimi Zohar
2025-03-20 1:51 ` Baoquan He
2025-03-20 13:06 ` Mimi Zohar
2025-03-21 16:18 ` steven chen
2025-03-18 1:04 ` steven chen [this message]
2025-03-19 10:12 ` [PATCH v10 3/8] kexec: define functions to map and unmap segments Baoquan He
2025-03-18 1:04 ` [PATCH v10 4/8] ima: kexec: skip IMA segment validation after kexec soft reboot steven chen
2025-03-19 10:16 ` Baoquan He
2025-03-18 1:04 ` [PATCH v10 5/8] ima: kexec: define functions to copy IMA log at soft boot steven chen
2025-03-18 1:04 ` [PATCH v10 6/8] ima: kexec: move IMA log copy from kexec load to execute steven chen
2025-03-19 20:53 ` Mimi Zohar
2025-03-21 16:20 ` steven chen
2025-03-20 2:06 ` Baoquan He
2025-03-21 16:23 ` steven chen
2025-03-24 11:00 ` Baoquan He
2025-03-25 22:27 ` steven chen
2025-03-26 2:27 ` Baoquan He
2025-03-26 22:46 ` steven chen
2025-03-26 23:44 ` Mimi Zohar
2025-03-18 1:04 ` [PATCH v10 7/8] ima: make the kexec extra memory configurable steven chen
2025-03-20 2:52 ` Baoquan He
2025-03-21 16:46 ` steven chen
2025-03-18 1:04 ` [PATCH v10 8/8] ima: measure kexec load and exec events as critical data steven chen
2025-03-20 2:59 ` Mimi Zohar
2025-03-21 16:49 ` steven chen
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=20250318010448.954-4-chenste@linux.microsoft.com \
--to=chenste@linux.microsoft.com \
--cc=James.Bottomley@HansenPartnership.com \
--cc=bauermann@kolabnow.com \
--cc=bhe@redhat.com \
--cc=code@tyhicks.com \
--cc=dyoung@redhat.com \
--cc=ebiederm@xmission.com \
--cc=eric.snowberg@oracle.com \
--cc=kexec@lists.infradead.org \
--cc=linux-integrity@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-security-module@vger.kernel.org \
--cc=madvenka@linux.microsoft.com \
--cc=nramas@linux.microsoft.com \
--cc=paul@paul-moore.com \
--cc=roberto.sassu@huawei.com \
--cc=roberto.sassu@huaweicloud.com \
--cc=stefanb@linux.ibm.com \
--cc=vgoyal@redhat.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;
as well as URLs for NNTP newsgroup(s).