2022-08-12 16:54:03

by Stefan Berger

[permalink] [raw]
Subject: [PATCH v7 0/6] tpm: Preserve TPM measurement log across kexec (ppc64)

The of-tree subsystem does not currently preserve the IBM vTPM 1.2 and
vTPM 2.0 measurement logs across a kexec on PowerVM and PowerKVM. This
series fixes this for the kexec_file_load() syscall using the flattened
device tree (fdt) to carry the TPM measurement log's buffer across kexec.

Stefan

v7:
- Added Nageswara's Tested-by tags
- Added back original comment to inline function and removed Jarkko's R-b tag

v6:
- Add __init to get_kexec_buffer as suggested by Jonathan
- Fixed issue detected by kernel test robot

v5:
- Rebased on 1 more patch that would otherwise create merge conflicts

v4:
- Rebased on 2 patches that would otherwise create merge conflicts;
posting these patches in this series with several tags removed so
krobot can test the series already
- Changes to individual patches documented in patch descripitons

v3:
- Moved TPM Open Firmware related function to drivers/char/tpm/eventlog/tpm_of.c

v2:
- rearranged patches
- fixed compilation issues for x86


Jonathan McDowell (1):
x86/kexec: Carry forward IMA measurement log on kexec

Palmer Dabbelt (1):
drivers: of: kexec ima: Support 32-bit platforms

Stefan Berger (3):
tpm: of: Make of-tree specific function commonly available
of: kexec: Refactor IMA buffer related functions to make them reusable
tpm/kexec: Duplicate TPM measurement log in of-tree for kexec

Vaibhav Jain (1):
of: check previous kernel's ima-kexec-buffer against memory bounds

arch/x86/Kconfig | 1 +
arch/x86/include/uapi/asm/bootparam.h | 9 +
arch/x86/kernel/e820.c | 6 +-
arch/x86/kernel/kexec-bzimage64.c | 42 +++-
arch/x86/kernel/setup.c | 63 +++++
drivers/char/tpm/eventlog/of.c | 31 +--
drivers/of/kexec.c | 342 ++++++++++++++++++++++----
include/linux/ima.h | 5 +
include/linux/kexec.h | 6 +
include/linux/of.h | 11 +-
include/linux/tpm.h | 36 +++
kernel/kexec_file.c | 6 +
security/integrity/ima/ima_kexec.c | 2 +-
13 files changed, 478 insertions(+), 82 deletions(-)


base-commit: 3d7cb6b04c3f3115719235cc6866b10326de34cd
--
2.35.1


2022-08-12 16:55:38

by Stefan Berger

[permalink] [raw]
Subject: [PATCH v7 3/6] x86/kexec: Carry forward IMA measurement log on kexec

From: Jonathan McDowell <[email protected]>

On kexec file load, the Integrity Measurement Architecture (IMA)
subsystem may verify the IMA signature of the kernel and initramfs, and
measure it. The command line parameters passed to the kernel in the
kexec call may also be measured by IMA.

A remote attestation service can verify a TPM quote based on the TPM
event log, the IMA measurement list and the TPM PCR data. This can
be achieved only if the IMA measurement log is carried over from the
current kernel to the next kernel across the kexec call.

PowerPC and ARM64 both achieve this using device tree with a
"linux,ima-kexec-buffer" node. x86 platforms generally don't make use of
device tree, so use the setup_data mechanism to pass the IMA buffer to
the new kernel.

Signed-off-by: Jonathan McDowell <[email protected]>
Signed-off-by: Borislav Petkov <[email protected]>
Reviewed-by: Mimi Zohar <[email protected]> # IMA function definitions
Link: https://lore.kernel.org/r/YmKyvlF3my1yWTvK@noodles-fedora-PC23Y6EG
---
arch/x86/Kconfig | 1 +
arch/x86/include/uapi/asm/bootparam.h | 9 ++++
arch/x86/kernel/e820.c | 6 +--
arch/x86/kernel/kexec-bzimage64.c | 42 +++++++++++++++++-
arch/x86/kernel/setup.c | 63 +++++++++++++++++++++++++++
drivers/of/kexec.c | 13 +++---
include/linux/ima.h | 5 +++
include/linux/of.h | 2 -
security/integrity/ima/ima_kexec.c | 2 +-
9 files changed, 127 insertions(+), 16 deletions(-)

diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index 52a7f91527fe..6d203b64a3af 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -2011,6 +2011,7 @@ config KEXEC_FILE
bool "kexec file based system call"
select KEXEC_CORE
select BUILD_BIN2C
+ select HAVE_IMA_KEXEC if IMA
depends on X86_64
depends on CRYPTO=y
depends on CRYPTO_SHA256=y
diff --git a/arch/x86/include/uapi/asm/bootparam.h b/arch/x86/include/uapi/asm/bootparam.h
index e02a8a8ef23c..be2b9ce52c76 100644
--- a/arch/x86/include/uapi/asm/bootparam.h
+++ b/arch/x86/include/uapi/asm/bootparam.h
@@ -11,6 +11,7 @@
#define SETUP_APPLE_PROPERTIES 5
#define SETUP_JAILHOUSE 6
#define SETUP_CC_BLOB 7
+#define SETUP_IMA 8

#define SETUP_INDIRECT (1<<31)

@@ -172,6 +173,14 @@ struct jailhouse_setup_data {
} __attribute__((packed)) v2;
} __attribute__((packed));

+/*
+ * IMA buffer setup data information from the previous kernel during kexec
+ */
+struct ima_setup_data {
+ __u64 addr;
+ __u64 size;
+} __attribute__((packed));
+
/* The so-called "zeropage" */
struct boot_params {
struct screen_info screen_info; /* 0x000 */
diff --git a/arch/x86/kernel/e820.c b/arch/x86/kernel/e820.c
index f267205f2d5a..9dac24680ff8 100644
--- a/arch/x86/kernel/e820.c
+++ b/arch/x86/kernel/e820.c
@@ -1017,10 +1017,10 @@ void __init e820__reserve_setup_data(void)
e820__range_update(pa_data, sizeof(*data)+data->len, E820_TYPE_RAM, E820_TYPE_RESERVED_KERN);

/*
- * SETUP_EFI is supplied by kexec and does not need to be
- * reserved.
+ * SETUP_EFI and SETUP_IMA are supplied by kexec and do not need
+ * to be reserved.
*/
- if (data->type != SETUP_EFI)
+ if (data->type != SETUP_EFI && data->type != SETUP_IMA)
e820__range_update_kexec(pa_data,
sizeof(*data) + data->len,
E820_TYPE_RAM, E820_TYPE_RESERVED_KERN);
diff --git a/arch/x86/kernel/kexec-bzimage64.c b/arch/x86/kernel/kexec-bzimage64.c
index 170d0fd68b1f..c63974e94272 100644
--- a/arch/x86/kernel/kexec-bzimage64.c
+++ b/arch/x86/kernel/kexec-bzimage64.c
@@ -186,11 +186,38 @@ setup_efi_state(struct boot_params *params, unsigned long params_load_addr,
}
#endif /* CONFIG_EFI */

+static void
+setup_ima_state(const struct kimage *image, struct boot_params *params,
+ unsigned long params_load_addr,
+ unsigned int ima_setup_data_offset)
+{
+#ifdef CONFIG_IMA_KEXEC
+ struct setup_data *sd = (void *)params + ima_setup_data_offset;
+ unsigned long setup_data_phys;
+ struct ima_setup_data *ima;
+
+ if (!image->ima_buffer_size)
+ return;
+
+ sd->type = SETUP_IMA;
+ sd->len = sizeof(*ima);
+
+ ima = (void *)sd + sizeof(struct setup_data);
+ ima->addr = image->ima_buffer_addr;
+ ima->size = image->ima_buffer_size;
+
+ /* Add setup data */
+ setup_data_phys = params_load_addr + ima_setup_data_offset;
+ sd->next = params->hdr.setup_data;
+ params->hdr.setup_data = setup_data_phys;
+#endif /* CONFIG_IMA_KEXEC */
+}
+
static int
setup_boot_parameters(struct kimage *image, struct boot_params *params,
unsigned long params_load_addr,
unsigned int efi_map_offset, unsigned int efi_map_sz,
- unsigned int efi_setup_data_offset)
+ unsigned int setup_data_offset)
{
unsigned int nr_e820_entries;
unsigned long long mem_k, start, end;
@@ -245,8 +272,15 @@ setup_boot_parameters(struct kimage *image, struct boot_params *params,
#ifdef CONFIG_EFI
/* Setup EFI state */
setup_efi_state(params, params_load_addr, efi_map_offset, efi_map_sz,
- efi_setup_data_offset);
+ setup_data_offset);
+ setup_data_offset += sizeof(struct setup_data) +
+ sizeof(struct efi_setup_data);
#endif
+
+ /* Setup IMA log buffer state */
+ setup_ima_state(image, params, params_load_addr,
+ setup_data_offset);
+
/* Setup EDD info */
memcpy(params->eddbuf, boot_params.eddbuf,
EDDMAXNR * sizeof(struct edd_info));
@@ -403,6 +437,10 @@ static void *bzImage64_load(struct kimage *image, char *kernel,
sizeof(struct setup_data) +
sizeof(struct efi_setup_data);

+ if (IS_ENABLED(CONFIG_IMA_KEXEC))
+ kbuf.bufsz += sizeof(struct setup_data) +
+ sizeof(struct ima_setup_data);
+
params = kzalloc(kbuf.bufsz, GFP_KERNEL);
if (!params)
return ERR_PTR(-ENOMEM);
diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c
index bd6c6fd373ae..53f863f28b4c 100644
--- a/arch/x86/kernel/setup.c
+++ b/arch/x86/kernel/setup.c
@@ -11,6 +11,7 @@
#include <linux/dma-map-ops.h>
#include <linux/dmi.h>
#include <linux/efi.h>
+#include <linux/ima.h>
#include <linux/init_ohci1394_dma.h>
#include <linux/initrd.h>
#include <linux/iscsi_ibft.h>
@@ -140,6 +141,11 @@ __visible unsigned long mmu_cr4_features __ro_after_init;
__visible unsigned long mmu_cr4_features __ro_after_init = X86_CR4_PAE;
#endif

+#ifdef CONFIG_IMA
+static phys_addr_t ima_kexec_buffer_phys;
+static size_t ima_kexec_buffer_size;
+#endif
+
/* Boot loader ID and version as integers, for the benefit of proc_dointvec */
int bootloader_type, bootloader_version;

@@ -330,6 +336,60 @@ static void __init reserve_initrd(void)
}
#endif /* CONFIG_BLK_DEV_INITRD */

+static void __init add_early_ima_buffer(u64 phys_addr)
+{
+#ifdef CONFIG_IMA
+ struct ima_setup_data *data;
+
+ data = early_memremap(phys_addr + sizeof(struct setup_data), sizeof(*data));
+ if (!data) {
+ pr_warn("setup: failed to memremap ima_setup_data entry\n");
+ return;
+ }
+
+ if (data->size) {
+ memblock_reserve(data->addr, data->size);
+ ima_kexec_buffer_phys = data->addr;
+ ima_kexec_buffer_size = data->size;
+ }
+
+ early_memunmap(data, sizeof(*data));
+#else
+ pr_warn("Passed IMA kexec data, but CONFIG_IMA not set. Ignoring.\n");
+#endif
+}
+
+#if defined(CONFIG_HAVE_IMA_KEXEC) && !defined(CONFIG_OF_FLATTREE)
+int __init ima_free_kexec_buffer(void)
+{
+ int rc;
+
+ if (!ima_kexec_buffer_size)
+ return -ENOENT;
+
+ rc = memblock_phys_free(ima_kexec_buffer_phys,
+ ima_kexec_buffer_size);
+ if (rc)
+ return rc;
+
+ ima_kexec_buffer_phys = 0;
+ ima_kexec_buffer_size = 0;
+
+ return 0;
+}
+
+int __init ima_get_kexec_buffer(void **addr, size_t *size)
+{
+ if (!ima_kexec_buffer_size)
+ return -ENOENT;
+
+ *addr = __va(ima_kexec_buffer_phys);
+ *size = ima_kexec_buffer_size;
+
+ return 0;
+}
+#endif
+
static void __init parse_setup_data(void)
{
struct setup_data *data;
@@ -355,6 +415,9 @@ static void __init parse_setup_data(void)
case SETUP_EFI:
parse_efi_setup(pa_data, data_len);
break;
+ case SETUP_IMA:
+ add_early_ima_buffer(pa_data);
+ break;
default:
break;
}
diff --git a/drivers/of/kexec.c b/drivers/of/kexec.c
index c4f9b6655a2e..548dd5b1b5c1 100644
--- a/drivers/of/kexec.c
+++ b/drivers/of/kexec.c
@@ -9,6 +9,7 @@
* Copyright (C) 2016 IBM Corporation
*/

+#include <linux/ima.h>
#include <linux/kernel.h>
#include <linux/kexec.h>
#include <linux/memblock.h>
@@ -115,6 +116,7 @@ static int do_get_kexec_buffer(const void *prop, int len, unsigned long *addr,
return 0;
}

+#ifdef CONFIG_HAVE_IMA_KEXEC
/**
* ima_get_kexec_buffer - get IMA buffer from the previous kernel
* @addr: On successful return, set to point to the buffer contents.
@@ -122,7 +124,7 @@ static int do_get_kexec_buffer(const void *prop, int len, unsigned long *addr,
*
* Return: 0 on success, negative errno on error.
*/
-int ima_get_kexec_buffer(void **addr, size_t *size)
+int __init ima_get_kexec_buffer(void **addr, size_t *size)
{
int ret, len;
unsigned long tmp_addr;
@@ -130,9 +132,6 @@ int ima_get_kexec_buffer(void **addr, size_t *size)
size_t tmp_size;
const void *prop;

- if (!IS_ENABLED(CONFIG_HAVE_IMA_KEXEC))
- return -ENOTSUPP;
-
prop = of_get_property(of_chosen, "linux,ima-kexec-buffer", &len);
if (!prop)
return -ENOENT;
@@ -166,16 +165,13 @@ int ima_get_kexec_buffer(void **addr, size_t *size)
/**
* ima_free_kexec_buffer - free memory used by the IMA buffer
*/
-int ima_free_kexec_buffer(void)
+int __init ima_free_kexec_buffer(void)
{
int ret;
unsigned long addr;
size_t size;
struct property *prop;

- if (!IS_ENABLED(CONFIG_HAVE_IMA_KEXEC))
- return -ENOTSUPP;
-
prop = of_find_property(of_chosen, "linux,ima-kexec-buffer", NULL);
if (!prop)
return -ENOENT;
@@ -190,6 +186,7 @@ int ima_free_kexec_buffer(void)

return memblock_phys_free(addr, size);
}
+#endif

/**
* remove_ima_buffer - remove the IMA buffer property and reservation from @fdt
diff --git a/include/linux/ima.h b/include/linux/ima.h
index 426b1744215e..81708ca0ebc7 100644
--- a/include/linux/ima.h
+++ b/include/linux/ima.h
@@ -140,6 +140,11 @@ static inline int ima_measure_critical_data(const char *event_label,

#endif /* CONFIG_IMA */

+#ifdef CONFIG_HAVE_IMA_KEXEC
+int __init ima_free_kexec_buffer(void);
+int __init ima_get_kexec_buffer(void **addr, size_t *size);
+#endif
+
#ifdef CONFIG_IMA_SECURE_AND_OR_TRUSTED_BOOT
extern bool arch_ima_get_secureboot(void);
extern const char * const *arch_get_ima_policy(void);
diff --git a/include/linux/of.h b/include/linux/of.h
index f0a5d6b10c5a..20a4e7cb7afe 100644
--- a/include/linux/of.h
+++ b/include/linux/of.h
@@ -441,8 +441,6 @@ void *of_kexec_alloc_and_setup_fdt(const struct kimage *image,
unsigned long initrd_load_addr,
unsigned long initrd_len,
const char *cmdline, size_t extra_fdt_size);
-int ima_get_kexec_buffer(void **addr, size_t *size);
-int ima_free_kexec_buffer(void);
#else /* CONFIG_OF */

static inline void of_core_init(void)
diff --git a/security/integrity/ima/ima_kexec.c b/security/integrity/ima/ima_kexec.c
index 13753136f03f..419dc405c831 100644
--- a/security/integrity/ima/ima_kexec.c
+++ b/security/integrity/ima/ima_kexec.c
@@ -137,7 +137,7 @@ void ima_add_kexec_buffer(struct kimage *image)
/*
* Restore the measurement list from the previous kernel.
*/
-void ima_load_kexec_buffer(void)
+void __init ima_load_kexec_buffer(void)
{
void *kexec_buffer = NULL;
size_t kexec_buffer_size = 0;
--
2.35.1

2022-08-12 17:22:02

by Stefan Berger

[permalink] [raw]
Subject: [PATCH v7 4/6] tpm: of: Make of-tree specific function commonly available

Simplify tpm_read_log_of() by moving reusable parts of the code into
an inline function that makes it commonly available so it can be
used also for kexec support. Call the new of_tpm_get_sml_parameters()
function from the TPM Open Firmware driver.

Signed-off-by: Stefan Berger <[email protected]>
Cc: Jarkko Sakkinen <[email protected]>
Cc: Jason Gunthorpe <[email protected]>
Cc: Rob Herring <[email protected]>
Cc: Frank Rowand <[email protected]>
Reviewed-by: Mimi Zohar <[email protected]>
Tested-by: Nageswara R Sastry <[email protected]>

---
v7:
- Added original comment back into inlined function

v4:
- converted to inline function
---
drivers/char/tpm/eventlog/of.c | 31 +++++------------------------
include/linux/tpm.h | 36 ++++++++++++++++++++++++++++++++++
2 files changed, 41 insertions(+), 26 deletions(-)

diff --git a/drivers/char/tpm/eventlog/of.c b/drivers/char/tpm/eventlog/of.c
index a9ce66d09a75..f9462d19632e 100644
--- a/drivers/char/tpm/eventlog/of.c
+++ b/drivers/char/tpm/eventlog/of.c
@@ -12,6 +12,7 @@

#include <linux/slab.h>
#include <linux/of.h>
+#include <linux/tpm.h>
#include <linux/tpm_eventlog.h>

#include "../tpm.h"
@@ -20,11 +21,10 @@
int tpm_read_log_of(struct tpm_chip *chip)
{
struct device_node *np;
- const u32 *sizep;
- const u64 *basep;
struct tpm_bios_log *log;
u32 size;
u64 base;
+ int ret;

log = &chip->log;
if (chip->dev.parent && chip->dev.parent->of_node)
@@ -35,30 +35,9 @@ int tpm_read_log_of(struct tpm_chip *chip)
if (of_property_read_bool(np, "powered-while-suspended"))
chip->flags |= TPM_CHIP_FLAG_ALWAYS_POWERED;

- sizep = of_get_property(np, "linux,sml-size", NULL);
- basep = of_get_property(np, "linux,sml-base", NULL);
- if (sizep == NULL && basep == NULL)
- return -ENODEV;
- if (sizep == NULL || basep == NULL)
- return -EIO;
-
- /*
- * For both vtpm/tpm, firmware has log addr and log size in big
- * endian format. But in case of vtpm, there is a method called
- * sml-handover which is run during kernel init even before
- * device tree is setup. This sml-handover function takes care
- * of endianness and writes to sml-base and sml-size in little
- * endian format. For this reason, vtpm doesn't need conversion
- * but physical tpm needs the conversion.
- */
- if (of_property_match_string(np, "compatible", "IBM,vtpm") < 0 &&
- of_property_match_string(np, "compatible", "IBM,vtpm20") < 0) {
- size = be32_to_cpup((__force __be32 *)sizep);
- base = be64_to_cpup((__force __be64 *)basep);
- } else {
- size = *sizep;
- base = *basep;
- }
+ ret = of_tpm_get_sml_parameters(np, &base, &size);
+ if (ret < 0)
+ return ret;

if (size == 0) {
dev_warn(&chip->dev, "%s: Event log area empty\n", __func__);
diff --git a/include/linux/tpm.h b/include/linux/tpm.h
index dfeb25a0362d..6356baaa1393 100644
--- a/include/linux/tpm.h
+++ b/include/linux/tpm.h
@@ -460,4 +460,40 @@ static inline struct tpm_chip *tpm_default_chip(void)
return NULL;
}
#endif
+
+#ifdef CONFIG_OF
+static inline int of_tpm_get_sml_parameters(struct device_node *np,
+ u64 *base, u32 *size)
+{
+ const u32 *sizep;
+ const u64 *basep;
+
+ sizep = of_get_property(np, "linux,sml-size", NULL);
+ basep = of_get_property(np, "linux,sml-base", NULL);
+ if (sizep == NULL && basep == NULL)
+ return -ENODEV;
+ if (sizep == NULL || basep == NULL)
+ return -EIO;
+
+ /*
+ * For both vtpm/tpm, firmware has log addr and log size in big
+ * endian format. But in case of vtpm, there is a method called
+ * sml-handover which is run during kernel init even before
+ * device tree is setup. This sml-handover function takes care
+ * of endianness and writes to sml-base and sml-size in little
+ * endian format. For this reason, vtpm doesn't need conversion
+ * but physical tpm needs the conversion.
+ */
+ if (of_property_match_string(np, "compatible", "IBM,vtpm") < 0 &&
+ of_property_match_string(np, "compatible", "IBM,vtpm20") < 0) {
+ *size = be32_to_cpup((__force __be32 *)sizep);
+ *base = be64_to_cpup((__force __be64 *)basep);
+ } else {
+ *size = *sizep;
+ *base = *basep;
+ }
+ return 0;
+}
+#endif
+
#endif
--
2.35.1

2022-08-12 17:23:52

by Stefan Berger

[permalink] [raw]
Subject: [PATCH v7 1/6] of: check previous kernel's ima-kexec-buffer against memory bounds

From: Vaibhav Jain <[email protected]>

Presently ima_get_kexec_buffer() doesn't check if the previous kernel's
ima-kexec-buffer lies outside the addressable memory range. This can result
in a kernel panic if the new kernel is booted with 'mem=X' arg and the
ima-kexec-buffer was allocated beyond that range by the previous kernel.
The panic is usually of the form below:

$ sudo kexec --initrd initrd vmlinux --append='mem=16G'

<snip>
BUG: Unable to handle kernel data access on read at 0xc000c01fff7f0000
Faulting instruction address: 0xc000000000837974
Oops: Kernel access of bad area, sig: 11 [#1]
<snip>
NIP [c000000000837974] ima_restore_measurement_list+0x94/0x6c0
LR [c00000000083b55c] ima_load_kexec_buffer+0xac/0x160
Call Trace:
[c00000000371fa80] [c00000000083b55c] ima_load_kexec_buffer+0xac/0x160
[c00000000371fb00] [c0000000020512c4] ima_init+0x80/0x108
[c00000000371fb70] [c0000000020514dc] init_ima+0x4c/0x120
[c00000000371fbf0] [c000000000012240] do_one_initcall+0x60/0x2c0
[c00000000371fcc0] [c000000002004ad0] kernel_init_freeable+0x344/0x3ec
[c00000000371fda0] [c0000000000128a4] kernel_init+0x34/0x1b0
[c00000000371fe10] [c00000000000ce64] ret_from_kernel_thread+0x5c/0x64
Instruction dump:
f92100b8 f92100c0 90e10090 910100a0 4182050c 282a0017 3bc00000 40810330
7c0802a6 fb610198 7c9b2378 f80101d0 <a1240000> 2c090001 40820614 e9240010
---[ end trace 0000000000000000 ]---

Fix this issue by checking returned PFN range of previous kernel's
ima-kexec-buffer with page_is_ram() to ensure correct memory bounds.

Fixes: 467d27824920 ("powerpc: ima: get the kexec buffer passed by the previous kernel")
Cc: Frank Rowand <[email protected]>
Cc: Prakhar Srivastava <[email protected]>
Cc: Lakshmi Ramasubramanian <[email protected]>
Cc: Thiago Jung Bauermann <[email protected]>
Cc: Rob Herring <[email protected]>
Cc: Ritesh Harjani <[email protected]>
Cc: Robin Murphy <[email protected]>
Signed-off-by: Vaibhav Jain <[email protected]>
Signed-off-by: Rob Herring <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
---
drivers/of/kexec.c | 17 +++++++++++++++++
1 file changed, 17 insertions(+)

diff --git a/drivers/of/kexec.c b/drivers/of/kexec.c
index 8d374cc552be..91b04b04eec4 100644
--- a/drivers/of/kexec.c
+++ b/drivers/of/kexec.c
@@ -126,6 +126,7 @@ int ima_get_kexec_buffer(void **addr, size_t *size)
{
int ret, len;
unsigned long tmp_addr;
+ unsigned long start_pfn, end_pfn;
size_t tmp_size;
const void *prop;

@@ -140,6 +141,22 @@ int ima_get_kexec_buffer(void **addr, size_t *size)
if (ret)
return ret;

+ /* Do some sanity on the returned size for the ima-kexec buffer */
+ if (!tmp_size)
+ return -ENOENT;
+
+ /*
+ * Calculate the PFNs for the buffer and ensure
+ * they are with in addressable memory.
+ */
+ start_pfn = PHYS_PFN(tmp_addr);
+ end_pfn = PHYS_PFN(tmp_addr + tmp_size - 1);
+ if (!page_is_ram(start_pfn) || !page_is_ram(end_pfn)) {
+ pr_warn("IMA buffer at 0x%lx, size = 0x%zx beyond memory\n",
+ tmp_addr, tmp_size);
+ return -EINVAL;
+ }
+
*addr = __va(tmp_addr);
*size = tmp_size;

--
2.35.1

2022-08-12 17:33:49

by Borislav Petkov

[permalink] [raw]
Subject: Re: [PATCH v7 3/6] x86/kexec: Carry forward IMA measurement log on kexec

On Fri, Aug 12, 2022 at 12:43:02PM -0400, Stefan Berger wrote:
> From: Jonathan McDowell <[email protected]>
>
> On kexec file load, the Integrity Measurement Architecture (IMA)
> subsystem may verify the IMA signature of the kernel and initramfs, and
> measure it. The command line parameters passed to the kernel in the
> kexec call may also be measured by IMA.
>
> A remote attestation service can verify a TPM quote based on the TPM
> event log, the IMA measurement list and the TPM PCR data. This can
> be achieved only if the IMA measurement log is carried over from the
> current kernel to the next kernel across the kexec call.
>
> PowerPC and ARM64 both achieve this using device tree with a
> "linux,ima-kexec-buffer" node. x86 platforms generally don't make use of
> device tree, so use the setup_data mechanism to pass the IMA buffer to
> the new kernel.
>
> Signed-off-by: Jonathan McDowell <[email protected]>
> Signed-off-by: Borislav Petkov <[email protected]>
> Reviewed-by: Mimi Zohar <[email protected]> # IMA function definitions
> Link: https://lore.kernel.org/r/YmKyvlF3my1yWTvK@noodles-fedora-PC23Y6EG

Is there any particular reason to keep sending a patch which is already
upstream?

--
Regards/Gruss,
Boris.

SUSE Software Solutions Germany GmbH
GF: Ivo Totev, Andrew Myers, Andrew McDonald, Martje Boudien Moerman
(HRB 36809, AG Nürnberg)

2022-08-12 17:36:48

by Stefan Berger

[permalink] [raw]
Subject: [PATCH v7 2/6] drivers: of: kexec ima: Support 32-bit platforms

From: Palmer Dabbelt <[email protected]>

RISC-V recently added kexec_file() support, which uses enables kexec
IMA. We're the first 32-bit platform to support this, so we found a
build bug.

Acked-by: Rob Herring <[email protected]>
Signed-off-by: Palmer Dabbelt <[email protected]>
Reviewed-by: Mimi Zohar <[email protected]>
---
drivers/of/kexec.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/of/kexec.c b/drivers/of/kexec.c
index 91b04b04eec4..c4f9b6655a2e 100644
--- a/drivers/of/kexec.c
+++ b/drivers/of/kexec.c
@@ -253,8 +253,8 @@ static int setup_ima_buffer(const struct kimage *image, void *fdt,
if (ret)
return -EINVAL;

- pr_debug("IMA buffer at 0x%llx, size = 0x%zx\n",
- image->ima_buffer_addr, image->ima_buffer_size);
+ pr_debug("IMA buffer at 0x%pa, size = 0x%zx\n",
+ &image->ima_buffer_addr, image->ima_buffer_size);

return 0;
}
--
2.35.1

2022-08-12 17:51:29

by Stefan Berger

[permalink] [raw]
Subject: Re: [PATCH v7 3/6] x86/kexec: Carry forward IMA measurement log on kexec



On 8/12/22 13:10, Borislav Petkov wrote:
> On Fri, Aug 12, 2022 at 12:43:02PM -0400, Stefan Berger wrote:
>> From: Jonathan McDowell <[email protected]>
>>
>> On kexec file load, the Integrity Measurement Architecture (IMA)
>> subsystem may verify the IMA signature of the kernel and initramfs, and
>> measure it. The command line parameters passed to the kernel in the
>> kexec call may also be measured by IMA.
>>
>> A remote attestation service can verify a TPM quote based on the TPM
>> event log, the IMA measurement list and the TPM PCR data. This can
>> be achieved only if the IMA measurement log is carried over from the
>> current kernel to the next kernel across the kexec call.
>>
>> PowerPC and ARM64 both achieve this using device tree with a
>> "linux,ima-kexec-buffer" node. x86 platforms generally don't make use of
>> device tree, so use the setup_data mechanism to pass the IMA buffer to
>> the new kernel.
>>
>> Signed-off-by: Jonathan McDowell <[email protected]>
>> Signed-off-by: Borislav Petkov <[email protected]>
>> Reviewed-by: Mimi Zohar <[email protected]> # IMA function definitions
>> Link: https://lore.kernel.org/r/YmKyvlF3my1yWTvK@noodles-fedora-PC23Y6EG
>
> Is there any particular reason to keep sending a patch which is already
> upstream?
>

Yes, so this series can be tested by krobot. I only based this series on
5.19 so far, so if it's upstreamed since then it will go missing next
time when I base it on 5.20-rc1 or so.

2022-08-12 19:22:13

by Borislav Petkov

[permalink] [raw]
Subject: Re: [PATCH v7 3/6] x86/kexec: Carry forward IMA measurement log on kexec

On Fri, Aug 12, 2022 at 01:14:38PM -0400, Stefan Berger wrote:
> Yes, so this series can be tested by krobot.

You mean Intel's 0day robot?

I believe that thing has by now enough logic to figure out which branch
to base patches ontop. Or maybe there's some magic incantation to tell
it which base commit to use so that you can simply do your patches ontop
of latest linux-next instead of having to carry upstreamed patches.

Also, there's a little point in testing against 5.19 when you wanna test
it against v6.0-rc1...

--
Regards/Gruss,
Boris.

SUSE Software Solutions Germany GmbH
GF: Ivo Totev, Andrew Myers, Andrew McDonald, Martje Boudien Moerman
(HRB 36809, AG Nürnberg)

2022-08-14 19:18:36

by Jarkko Sakkinen

[permalink] [raw]
Subject: Re: [PATCH v7 4/6] tpm: of: Make of-tree specific function commonly available

On Fri, Aug 12, 2022 at 12:43:03PM -0400, Stefan Berger wrote:
> Simplify tpm_read_log_of() by moving reusable parts of the code into
> an inline function that makes it commonly available so it can be
> used also for kexec support. Call the new of_tpm_get_sml_parameters()
> function from the TPM Open Firmware driver.
>
> Signed-off-by: Stefan Berger <[email protected]>
> Cc: Jarkko Sakkinen <[email protected]>
> Cc: Jason Gunthorpe <[email protected]>
> Cc: Rob Herring <[email protected]>
> Cc: Frank Rowand <[email protected]>
> Reviewed-by: Mimi Zohar <[email protected]>
> Tested-by: Nageswara R Sastry <[email protected]>
>
> ---
> v7:
> - Added original comment back into inlined function
>
> v4:
> - converted to inline function
> ---
> drivers/char/tpm/eventlog/of.c | 31 +++++------------------------
> include/linux/tpm.h | 36 ++++++++++++++++++++++++++++++++++
> 2 files changed, 41 insertions(+), 26 deletions(-)
>
> diff --git a/drivers/char/tpm/eventlog/of.c b/drivers/char/tpm/eventlog/of.c
> index a9ce66d09a75..f9462d19632e 100644
> --- a/drivers/char/tpm/eventlog/of.c
> +++ b/drivers/char/tpm/eventlog/of.c
> @@ -12,6 +12,7 @@
>
> #include <linux/slab.h>
> #include <linux/of.h>
> +#include <linux/tpm.h>
> #include <linux/tpm_eventlog.h>
>
> #include "../tpm.h"
> @@ -20,11 +21,10 @@
> int tpm_read_log_of(struct tpm_chip *chip)
> {
> struct device_node *np;
> - const u32 *sizep;
> - const u64 *basep;
> struct tpm_bios_log *log;
> u32 size;
> u64 base;
> + int ret;
>
> log = &chip->log;
> if (chip->dev.parent && chip->dev.parent->of_node)
> @@ -35,30 +35,9 @@ int tpm_read_log_of(struct tpm_chip *chip)
> if (of_property_read_bool(np, "powered-while-suspended"))
> chip->flags |= TPM_CHIP_FLAG_ALWAYS_POWERED;
>
> - sizep = of_get_property(np, "linux,sml-size", NULL);
> - basep = of_get_property(np, "linux,sml-base", NULL);
> - if (sizep == NULL && basep == NULL)
> - return -ENODEV;
> - if (sizep == NULL || basep == NULL)
> - return -EIO;
> -
> - /*
> - * For both vtpm/tpm, firmware has log addr and log size in big
> - * endian format. But in case of vtpm, there is a method called
> - * sml-handover which is run during kernel init even before
> - * device tree is setup. This sml-handover function takes care
> - * of endianness and writes to sml-base and sml-size in little
> - * endian format. For this reason, vtpm doesn't need conversion
> - * but physical tpm needs the conversion.
> - */
> - if (of_property_match_string(np, "compatible", "IBM,vtpm") < 0 &&
> - of_property_match_string(np, "compatible", "IBM,vtpm20") < 0) {
> - size = be32_to_cpup((__force __be32 *)sizep);
> - base = be64_to_cpup((__force __be64 *)basep);
> - } else {
> - size = *sizep;
> - base = *basep;
> - }
> + ret = of_tpm_get_sml_parameters(np, &base, &size);
> + if (ret < 0)
> + return ret;
>
> if (size == 0) {
> dev_warn(&chip->dev, "%s: Event log area empty\n", __func__);
> diff --git a/include/linux/tpm.h b/include/linux/tpm.h
> index dfeb25a0362d..6356baaa1393 100644
> --- a/include/linux/tpm.h
> +++ b/include/linux/tpm.h
> @@ -460,4 +460,40 @@ static inline struct tpm_chip *tpm_default_chip(void)
> return NULL;
> }
> #endif
> +
> +#ifdef CONFIG_OF
> +static inline int of_tpm_get_sml_parameters(struct device_node *np,
> + u64 *base, u32 *size)
> +{
> + const u32 *sizep;
> + const u64 *basep;
> +
> + sizep = of_get_property(np, "linux,sml-size", NULL);
> + basep = of_get_property(np, "linux,sml-base", NULL);
> + if (sizep == NULL && basep == NULL)
> + return -ENODEV;
> + if (sizep == NULL || basep == NULL)
> + return -EIO;
> +
> + /*
> + * For both vtpm/tpm, firmware has log addr and log size in big
> + * endian format. But in case of vtpm, there is a method called
> + * sml-handover which is run during kernel init even before
> + * device tree is setup. This sml-handover function takes care
> + * of endianness and writes to sml-base and sml-size in little
> + * endian format. For this reason, vtpm doesn't need conversion
> + * but physical tpm needs the conversion.
> + */
> + if (of_property_match_string(np, "compatible", "IBM,vtpm") < 0 &&
> + of_property_match_string(np, "compatible", "IBM,vtpm20") < 0) {
> + *size = be32_to_cpup((__force __be32 *)sizep);
> + *base = be64_to_cpup((__force __be64 *)basep);
> + } else {
> + *size = *sizep;
> + *base = *basep;
> + }
> + return 0;
> +}
> +#endif
> +
> #endif
> --
> 2.35.1
>

Reviewed-by: Jarkko Sakkinen <[email protected]>

BR, Jarkkko

2022-08-14 19:18:42

by Jarkko Sakkinen

[permalink] [raw]
Subject: Re: [PATCH v7 4/6] tpm: of: Make of-tree specific function commonly available

On Sun, Aug 14, 2022 at 10:16:09PM +0300, Jarkko Sakkinen wrote:
> On Fri, Aug 12, 2022 at 12:43:03PM -0400, Stefan Berger wrote:
> > Simplify tpm_read_log_of() by moving reusable parts of the code into
> > an inline function that makes it commonly available so it can be
> > used also for kexec support. Call the new of_tpm_get_sml_parameters()
> > function from the TPM Open Firmware driver.
> >
> > Signed-off-by: Stefan Berger <[email protected]>
> > Cc: Jarkko Sakkinen <[email protected]>
> > Cc: Jason Gunthorpe <[email protected]>
> > Cc: Rob Herring <[email protected]>
> > Cc: Frank Rowand <[email protected]>
> > Reviewed-by: Mimi Zohar <[email protected]>
> > Tested-by: Nageswara R Sastry <[email protected]>
> >
> > ---
> > v7:
> > - Added original comment back into inlined function
> >
> > v4:
> > - converted to inline function
> > ---
> > drivers/char/tpm/eventlog/of.c | 31 +++++------------------------
> > include/linux/tpm.h | 36 ++++++++++++++++++++++++++++++++++
> > 2 files changed, 41 insertions(+), 26 deletions(-)
> >
> > diff --git a/drivers/char/tpm/eventlog/of.c b/drivers/char/tpm/eventlog/of.c
> > index a9ce66d09a75..f9462d19632e 100644
> > --- a/drivers/char/tpm/eventlog/of.c
> > +++ b/drivers/char/tpm/eventlog/of.c
> > @@ -12,6 +12,7 @@
> >
> > #include <linux/slab.h>
> > #include <linux/of.h>
> > +#include <linux/tpm.h>
> > #include <linux/tpm_eventlog.h>
> >
> > #include "../tpm.h"
> > @@ -20,11 +21,10 @@
> > int tpm_read_log_of(struct tpm_chip *chip)
> > {
> > struct device_node *np;
> > - const u32 *sizep;
> > - const u64 *basep;
> > struct tpm_bios_log *log;
> > u32 size;
> > u64 base;
> > + int ret;
> >
> > log = &chip->log;
> > if (chip->dev.parent && chip->dev.parent->of_node)
> > @@ -35,30 +35,9 @@ int tpm_read_log_of(struct tpm_chip *chip)
> > if (of_property_read_bool(np, "powered-while-suspended"))
> > chip->flags |= TPM_CHIP_FLAG_ALWAYS_POWERED;
> >
> > - sizep = of_get_property(np, "linux,sml-size", NULL);
> > - basep = of_get_property(np, "linux,sml-base", NULL);
> > - if (sizep == NULL && basep == NULL)
> > - return -ENODEV;
> > - if (sizep == NULL || basep == NULL)
> > - return -EIO;
> > -
> > - /*
> > - * For both vtpm/tpm, firmware has log addr and log size in big
> > - * endian format. But in case of vtpm, there is a method called
> > - * sml-handover which is run during kernel init even before
> > - * device tree is setup. This sml-handover function takes care
> > - * of endianness and writes to sml-base and sml-size in little
> > - * endian format. For this reason, vtpm doesn't need conversion
> > - * but physical tpm needs the conversion.
> > - */
> > - if (of_property_match_string(np, "compatible", "IBM,vtpm") < 0 &&
> > - of_property_match_string(np, "compatible", "IBM,vtpm20") < 0) {
> > - size = be32_to_cpup((__force __be32 *)sizep);
> > - base = be64_to_cpup((__force __be64 *)basep);
> > - } else {
> > - size = *sizep;
> > - base = *basep;
> > - }
> > + ret = of_tpm_get_sml_parameters(np, &base, &size);
> > + if (ret < 0)
> > + return ret;
> >
> > if (size == 0) {
> > dev_warn(&chip->dev, "%s: Event log area empty\n", __func__);
> > diff --git a/include/linux/tpm.h b/include/linux/tpm.h
> > index dfeb25a0362d..6356baaa1393 100644
> > --- a/include/linux/tpm.h
> > +++ b/include/linux/tpm.h
> > @@ -460,4 +460,40 @@ static inline struct tpm_chip *tpm_default_chip(void)
> > return NULL;
> > }
> > #endif
> > +
> > +#ifdef CONFIG_OF
> > +static inline int of_tpm_get_sml_parameters(struct device_node *np,
> > + u64 *base, u32 *size)
> > +{
> > + const u32 *sizep;
> > + const u64 *basep;
> > +
> > + sizep = of_get_property(np, "linux,sml-size", NULL);
> > + basep = of_get_property(np, "linux,sml-base", NULL);
> > + if (sizep == NULL && basep == NULL)
> > + return -ENODEV;
> > + if (sizep == NULL || basep == NULL)
> > + return -EIO;
> > +
> > + /*
> > + * For both vtpm/tpm, firmware has log addr and log size in big
> > + * endian format. But in case of vtpm, there is a method called
> > + * sml-handover which is run during kernel init even before
> > + * device tree is setup. This sml-handover function takes care
> > + * of endianness and writes to sml-base and sml-size in little
> > + * endian format. For this reason, vtpm doesn't need conversion
> > + * but physical tpm needs the conversion.
> > + */
> > + if (of_property_match_string(np, "compatible", "IBM,vtpm") < 0 &&
> > + of_property_match_string(np, "compatible", "IBM,vtpm20") < 0) {
> > + *size = be32_to_cpup((__force __be32 *)sizep);
> > + *base = be64_to_cpup((__force __be64 *)basep);
> > + } else {
> > + *size = *sizep;
> > + *base = *basep;
> > + }
> > + return 0;
> > +}
> > +#endif
> > +
> > #endif
> > --
> > 2.35.1
> >
>
> Reviewed-by: Jarkko Sakkinen <[email protected]>
>
> BR, Jarkkko

Should I pick this or will the full patch set be picked
by someone?

BR, Jarkko

2022-08-15 07:16:40

by Coiby Xu

[permalink] [raw]
Subject: Re: [PATCH v7 0/6] tpm: Preserve TPM measurement log across kexec (ppc64)

On Mon, Aug 15, 2022 at 02:48:13PM +0800, Coiby Xu wrote:
>I can confirm this patch set fixes an issue that guest kdump kernel
>crashes on POWER9 host by applying it to 5.19.1 (there is a conflict
>when applying this patch set to latest kernel i.e. 6.0.0-rc1).

FYI, here's the error of applying it to 6.0.0-rc1,

[root@localhost linux]# git am ../v7_tpm_log.mbox
Applying: of: check previous kernel's ima-kexec-buffer against memory bounds
error: patch failed: drivers/of/kexec.c:126
error: drivers/of/kexec.c: patch does not apply
Patch failed at 0001 of: check previous kernel's ima-kexec-buffer against memory bounds
hint: Use 'git am --show-current-patch=diff' to see the failed patch

--
Best regards,
Coiby

2022-08-15 07:26:24

by Coiby Xu

[permalink] [raw]
Subject: Re: [PATCH v7 0/6] tpm: Preserve TPM measurement log across kexec (ppc64)

I can confirm this patch set fixes an issue that guest kdump kernel
crashes on POWER9 host by applying it to 5.19.1 (there is a conflict
when applying this patch set to latest kernel i.e. 6.0.0-rc1).

Tested-by: Coiby Xu <[email protected]>

Previously, the issue can be reproduced as follows,

1. revert commit 7c5ed82b800d ("powerpc: Set crashkernel offset to mid
of RMA region") which masks the issue
2. build & boot the kernel with crashkernel=512M
3. load kdump kernel and trigger kernel crash,
[ 4.209792] Oops: Kernel access of bad area, sig: 11 [#1]
[ 4.210373] LE PAGE_SIZE=64K MMU=Radix SMP NR_CPUS=2048 NUMA pSeries
[ 4.210985] Modules linked in:
[ 4.211570] CPU: 12 PID: 1 Comm: swapper/12 Not tainted 6.0.0-rc1+ #3
[ 4.212204] NIP: c0000000080a6540 LR: c00000000840c630 CTR: 0000000000000800
[ 4.212871] REGS: c00000000e66b130 TRAP: 0300 Not tainted (6.0.0-rc1+)
[ 4.213529] MSR: 800000000280b033 <SF,VEC,VSX,EE,FP,ME,IR,DR,RI,LE> CR: 24000280 XER: 0000005b
[ 4.214242] CFAR: c0000000080a6528 DAR: c00000002ffb0000 DSISR: 40000000 IRQMASK: 0
[ 4.214242] GPR00: 000000000e000000 c00000000e66b3d0 c00000000aa69a00 c0000000117c0000
[ 4.214242] GPR04: c00000002ffb0000 0000000000040000 0000000000000800 03fffffffee84000
[ 4.214242] GPR08: 0000000080000000 0000000000000010 0000000000000020 0000000000000030
[ 4.214242] GPR12: 0000000000000040 c00000000ad61000 0000000000000050 0000000000000060
[ 4.214242] GPR16: 0000000000000070 0000000000000000 0000000000000000 0000000000000000
[ 4.214242] GPR20: 0000000000000000 0000000000000000 c000000008f7ebd8 c00000000e418420
[ 4.214242] GPR24: c00000000ad3c389 c000000008f7ed60 c00000000ecc9000 c000000011271848
[ 4.214242] GPR28: c000000027fcee5c c00000002ffb0000 0000000000040000 c0000000117c0000
[ 4.220176] NIP [c0000000080a6540] memcpy_power7+0x400/0x7d0
[ 4.220808] LR [c00000000840c630] kmemdup+0x50/0x80
[ 4.221428] Call Trace:
[ 4.222006] [c00000000e66b3d0] [c0000000080a63b4] memcpy_power7+0x274/0x7d0 (unreliable)
[ 4.222662] [c00000000e66b4d0] [c00000000840c630] kmemdup+0x50/0x80
[ 4.223293] [c00000000e66b510] [c000000008973ee0] tpm_read_log_of+0x110/0x1f0
[ 4.223929] [c00000000e66b5a0] [c000000008973020] tpm_bios_log_setup+0x80/0x250
[ 4.224552] [c00000000e66b630] [c00000000896b938] tpm_chip_register.part.0+0x38/0x2a0
[ 4.225170] [c00000000e66b6b0] [c000000008979a80] tpm_ibmvtpm_probe+0x530/0x7d0
[ 4.225777] [c00000000e66b790] [c0000000081055e4] vio_bus_probe+0x94/0x150
[ 4.226366] [c00000000e66b7e0] [c0000000089936d4] really_probe+0x104/0x550
[ 4.226947] [c00000000e66b860] [c000000008993bd4] __driver_probe_device+0xb4/0x240
[ 4.227560] [c00000000e66b8e0] [c000000008993db4] driver_probe_device+0x54/0x130
[ 4.228159] [c00000000e66b920] [c000000008994a88] __driver_attach+0x128/0x2d0
[ 4.228748] [c00000000e66b9a0] [c00000000898fcf8] bus_for_each_dev+0xa8/0x130
[ 4.229325] [c00000000e66ba00] [c000000008992bd4] driver_attach+0x34/0x50
[ 4.229887] [c00000000e66ba20] [c0000000089922d8] bus_add_driver+0x218/0x300
[ 4.230453] [c00000000e66bab0] [c000000008995f94] driver_register+0xb4/0x1c0
[ 4.231012] [c00000000e66bb20] [c000000008103fb0] __vio_register_driver+0x80/0xf0
[ 4.231569] [c00000000e66bba0] [c00000000a06807c] ibmvtpm_module_init+0x34/0x48
[ 4.232119] [c00000000e66bbc0] [c000000008011c14] do_one_initcall+0x64/0x300
[ 4.232664] [c00000000e66bca0] [c00000000a0053f0] do_initcalls+0x13c/0x190
[ 4.233183] [c00000000e66bd50] [c00000000a00570c] kernel_init_freeable+0x22c/0x2a0
[ 4.233706] [c00000000e66bdb0] [c000000008012240] kernel_init+0x30/0x1a0
[ 4.234204] [c00000000e66be10] [c00000000800ca54] ret_from_kernel_thread+0x5c/0x64
[ 4.234721] Instruction dump:
[ 4.235191] fa010080 39800040 39c00050 39e00060 3a000070 7cc903a6 48000018 60000000
[ 4.235738] 60000000 60000000 60000000 60000000 <7ce020ce> 7cc448ce 7ca450ce 7c8458ce
[ 4.236302] ---[ end trace 0000000000000000 ]---

On Fri, Aug 12, 2022 at 12:42:59PM -0400, Stefan Berger wrote:
>The of-tree subsystem does not currently preserve the IBM vTPM 1.2 and
>vTPM 2.0 measurement logs across a kexec on PowerVM and PowerKVM. This
>series fixes this for the kexec_file_load() syscall using the flattened
>device tree (fdt) to carry the TPM measurement log's buffer across kexec.
>
> Stefan
>
>v7:
> - Added Nageswara's Tested-by tags
> - Added back original comment to inline function and removed Jarkko's R-b tag
>
>v6:
> - Add __init to get_kexec_buffer as suggested by Jonathan
> - Fixed issue detected by kernel test robot
>
>v5:
> - Rebased on 1 more patch that would otherwise create merge conflicts
>
>v4:
> - Rebased on 2 patches that would otherwise create merge conflicts;
> posting these patches in this series with several tags removed so
> krobot can test the series already
> - Changes to individual patches documented in patch descripitons
>
>v3:
> - Moved TPM Open Firmware related function to drivers/char/tpm/eventlog/tpm_of.c
>
>v2:
> - rearranged patches
> - fixed compilation issues for x86
>
>
>Jonathan McDowell (1):
> x86/kexec: Carry forward IMA measurement log on kexec
>
>Palmer Dabbelt (1):
> drivers: of: kexec ima: Support 32-bit platforms
>
>Stefan Berger (3):
> tpm: of: Make of-tree specific function commonly available
> of: kexec: Refactor IMA buffer related functions to make them reusable
> tpm/kexec: Duplicate TPM measurement log in of-tree for kexec
>
>Vaibhav Jain (1):
> of: check previous kernel's ima-kexec-buffer against memory bounds
>
> arch/x86/Kconfig | 1 +
> arch/x86/include/uapi/asm/bootparam.h | 9 +
> arch/x86/kernel/e820.c | 6 +-
> arch/x86/kernel/kexec-bzimage64.c | 42 +++-
> arch/x86/kernel/setup.c | 63 +++++
> drivers/char/tpm/eventlog/of.c | 31 +--
> drivers/of/kexec.c | 342 ++++++++++++++++++++++----
> include/linux/ima.h | 5 +
> include/linux/kexec.h | 6 +
> include/linux/of.h | 11 +-
> include/linux/tpm.h | 36 +++
> kernel/kexec_file.c | 6 +
> security/integrity/ima/ima_kexec.c | 2 +-
> 13 files changed, 478 insertions(+), 82 deletions(-)
>
>
>base-commit: 3d7cb6b04c3f3115719235cc6866b10326de34cd
>--
>2.35.1
>
>
>_______________________________________________
>kexec mailing list
>[email protected]
>http://lists.infradead.org/mailman/listinfo/kexec
>

--
Best regards,
Coiby

2022-08-15 13:36:57

by Stefan Berger

[permalink] [raw]
Subject: Re: [PATCH v7 0/6] tpm: Preserve TPM measurement log across kexec (ppc64)



On 8/15/22 02:48, Coiby Xu wrote:
> I can confirm this patch set fixes an issue that guest kdump kernel
> crashes on POWER9 host by applying it to 5.19.1 (there is a conflict
> when applying this patch set to latest kernel i.e. 6.0.0-rc1)

I rebased it. 2 of the borrowed patches disappeared now since they are
upstream already and the rest applied without conflict...

>
> Tested-by: Coiby Xu <[email protected]>

Thanks.