[PATCH 0/6] arm64: make kexec_file able to load zboot image

[PATCH 0/6] arm64: make kexec_file able to load zboot image

[Pingfan Liu]

After introducing zboot image, kexec_file can not load and jump to the
new style image. Hence it demands a method to load the new kernel.

The crux of the problem lies in when and how to decompress the Image.gz.
There are three possible courses to take: -1. in user space, but hard to
achieve due to the signature verification inside the kernel.  -2. at the
boot time, let the efi_zboot_entry() handles it, which means a simulated
EFI service should be provided to that entry, especially about how to be
aware of the memory layout.  -3. in kernel space, during the file load
of the zboot image. At that point, the kernel masters the whole memory
information, and easily allocates a suitable memory for the decompressed
kernel image. (I think this is similar to what grub does today).

The core of this series is [5/6].  [3,6/6] handles the config option.
The assumption of [3/6] is kexec_file_load is independent of zboot,
especially it can load kernel images compressed with different
compression method.  [6/6] is if EFI_ZBOOT, the corresponding
decompression method should be included.


Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Will Deacon <will@kernel.org>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Ard Biesheuvel <ardb@kernel.org>
Cc: kexec@lists.infradead.org
To: linux-arm-kernel@lists.infradead.org
To: linux-kernel@vger.kernel.org

Pingfan Liu (6):
  arm64: kexec: Rename kexec_image.c to kexec_raw_image.c
  lib/decompress: Introduce decompress_method_by_name()
  arm64: Kconfig: Pick decompressing method for kexec file load
  lib/decompress: Keep decompress routines based on selection
  arm64: kexec: Introduce zboot image loader
  init/Kconfig: Select decompressing method if compressing kernel

 arch/arm64/Kconfig                            |  59 ++++++
 arch/arm64/include/asm/kexec.h                |   4 +-
 arch/arm64/kernel/Makefile                    |   2 +-
 .../{kexec_image.c => kexec_raw_image.c}      |   2 +-
 arch/arm64/kernel/kexec_zboot_image.c         | 186 ++++++++++++++++++
 arch/arm64/kernel/machine_kexec.c             |   1 +
 arch/arm64/kernel/machine_kexec_file.c        |   3 +-
 include/linux/decompress/generic.h            |   2 +
 include/linux/decompress/mm.h                 |   9 +-
 include/linux/zboot.h                         |  26 +++
 init/Kconfig                                  |   7 +
 lib/Kconfig                                   |   3 +
 lib/decompress.c                              |  17 +-
 13 files changed, 314 insertions(+), 7 deletions(-)
 rename arch/arm64/kernel/{kexec_image.c => kexec_raw_image.c} (98%)
 create mode 100644 arch/arm64/kernel/kexec_zboot_image.c
 create mode 100644 include/linux/zboot.h

-- 
2.31.1


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH 1/6] arm64: kexec: Rename kexec_image.c to kexec_raw_image.c

[Pingfan Liu]

With the emergence of zboot image format, kexec file load needs to
support multiple formats. In order to better distinguish the file's
purpose, renaming kexec_image.c to kexec_raw_image.c.

Signed-off-by: Pingfan Liu <kernelfans@gmail.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Will Deacon <will@kernel.org>
Cc: Mimi Zohar <zohar@linux.ibm.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: "Naveen N. Rao" <naveen.n.rao@linux.vnet.ibm.com>
Cc: Ard Biesheuvel <ardb@kernel.org>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: kexec@lists.infradead.org
To: linux-arm-kernel@lists.infradead.org
---
 arch/arm64/include/asm/kexec.h                         | 2 +-
 arch/arm64/kernel/Makefile                             | 2 +-
 arch/arm64/kernel/{kexec_image.c => kexec_raw_image.c} | 2 +-
 arch/arm64/kernel/machine_kexec_file.c                 | 2 +-
 4 files changed, 4 insertions(+), 4 deletions(-)
 rename arch/arm64/kernel/{kexec_image.c => kexec_raw_image.c} (98%)

diff --git a/arch/arm64/include/asm/kexec.h b/arch/arm64/include/asm/kexec.h
index 559bfae26715..3f3d5a6830b7 100644
--- a/arch/arm64/include/asm/kexec.h
+++ b/arch/arm64/include/asm/kexec.h
@@ -125,7 +125,7 @@ struct kimage_arch {
 };
 
 #ifdef CONFIG_KEXEC_FILE
-extern const struct kexec_file_ops kexec_image_ops;
+extern const struct kexec_file_ops kexec_raw_ops;
 
 int arch_kimage_file_post_load_cleanup(struct kimage *image);
 #define arch_kimage_file_post_load_cleanup arch_kimage_file_post_load_cleanup
diff --git a/arch/arm64/kernel/Makefile b/arch/arm64/kernel/Makefile
index ceba6792f5b3..99b52710606a 100644
--- a/arch/arm64/kernel/Makefile
+++ b/arch/arm64/kernel/Makefile
@@ -63,7 +63,7 @@ obj-$(CONFIG_HIBERNATION)		+= hibernate.o hibernate-asm.o
 obj-$(CONFIG_ELF_CORE)			+= elfcore.o
 obj-$(CONFIG_KEXEC_CORE)		+= machine_kexec.o relocate_kernel.o	\
 					   cpu-reset.o
-obj-$(CONFIG_KEXEC_FILE)		+= machine_kexec_file.o kexec_image.o
+obj-$(CONFIG_KEXEC_FILE)		+= machine_kexec_file.o kexec_raw_image.o
 obj-$(CONFIG_ARM64_RELOC_TEST)		+= arm64-reloc-test.o
 arm64-reloc-test-y := reloc_test_core.o reloc_test_syms.o
 obj-$(CONFIG_CRASH_DUMP)		+= crash_dump.o
diff --git a/arch/arm64/kernel/kexec_image.c b/arch/arm64/kernel/kexec_raw_image.c
similarity index 98%
rename from arch/arm64/kernel/kexec_image.c
rename to arch/arm64/kernel/kexec_raw_image.c
index 5ed6a585f21f..2b3412b3ad2c 100644
--- a/arch/arm64/kernel/kexec_image.c
+++ b/arch/arm64/kernel/kexec_raw_image.c
@@ -129,7 +129,7 @@ static void *image_load(struct kimage *image,
 	return NULL;
 }
 
-const struct kexec_file_ops kexec_image_ops = {
+const struct kexec_file_ops kexec_raw_ops = {
 	.probe = image_probe,
 	.load = image_load,
 #ifdef CONFIG_KEXEC_IMAGE_VERIFY_SIG
diff --git a/arch/arm64/kernel/machine_kexec_file.c b/arch/arm64/kernel/machine_kexec_file.c
index a11a6e14ba89..0738020507d1 100644
--- a/arch/arm64/kernel/machine_kexec_file.c
+++ b/arch/arm64/kernel/machine_kexec_file.c
@@ -23,7 +23,7 @@
 #include <linux/vmalloc.h>
 
 const struct kexec_file_ops * const kexec_file_loaders[] = {
-	&kexec_image_ops,
+	&kexec_raw_ops,
 	NULL
 };
 
-- 
2.31.1


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH 2/6] lib/decompress: Introduce decompress_method_by_name()

[Pingfan Liu]

The zboot image packs the compressed file in the data section. Instead
of starting with the zip file header. It records the compressing method
name 'gzip','lzma' etc in the zboot image header.

Hence it is easier to decide the decompressing method by the name than
by the magic number.

Signed-off-by: Pingfan Liu <kernelfans@gmail.com>
Cc: Ard Biesheuvel <ardb@kernel.org>
Cc: kexec@lists.infradead.org
To: linux-kernel@vger.kernel.org
---
 include/linux/decompress/generic.h |  2 ++
 lib/decompress.c                   | 14 +++++++++++++-
 2 files changed, 15 insertions(+), 1 deletion(-)

diff --git a/include/linux/decompress/generic.h b/include/linux/decompress/generic.h
index 207d80138db5..077f15ce77b9 100644
--- a/include/linux/decompress/generic.h
+++ b/include/linux/decompress/generic.h
@@ -37,4 +37,6 @@ typedef int (*decompress_fn) (unsigned char *inbuf, long len,
 decompress_fn decompress_method(const unsigned char *inbuf, long len,
 				const char **name);
 
+decompress_fn decompress_method_by_name(const unsigned char *name);
+
 #endif
diff --git a/lib/decompress.c b/lib/decompress.c
index ab3fc90ffc64..8dd6f87e885f 100644
--- a/lib/decompress.c
+++ b/lib/decompress.c
@@ -2,7 +2,7 @@
 /*
  * decompress.c
  *
- * Detect the decompression method based on magic number
+ * Detect the decompression method based on magic number or name
  */
 
 #include <linux/decompress/generic.h>
@@ -82,3 +82,15 @@ decompress_fn __init decompress_method(const unsigned char *inbuf, long len,
 		*name = cf->name;
 	return cf->decompressor;
 }
+
+decompress_fn __init decompress_method_by_name(const unsigned char *name)
+{
+	const struct compress_format *cf;
+
+	for (cf = compressed_formats; cf->name; cf++) {
+		if (!strcmp(name, cf->name))
+			break;
+
+	}
+	return cf->decompressor;
+}
-- 
2.31.1


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH 3/6] arm64: Kconfig: Pick decompressing method for kexec file load

[Pingfan Liu]

After introducing the zboot image, kexec file load should be able to
decompress the Image.gz. (Do in the later patch)

Unlike efi_zboot_entry() which knows the decompression method at the
built time, kexec may loads compressed kernels with variant compression
methods, hence it is helpful to include as many decompression method as
possible.  Here provide an opportunity to let users select at their
will.

Besides this, introduce an extra config option 'HAVE_KEXEC_DECOMPRESS' to
distinguish the reference to decompression routine between kexec and boot.
(used in later patch to keep the routine out of .init.text section)

Signed-off-by: Pingfan Liu <kernelfans@gmail.com>
Cc: Will Deacon <will@kernel.org>
Cc: Nick Terrell <terrelln@fb.com>
Cc: Herbert Xu <herbert@gondor.apana.org.au>
Cc: Eric Biggers <ebiggers@google.com>
Cc: "Jason A. Donenfeld" <Jason@zx2c4.com>
Cc: Yury Norov <yury.norov@gmail.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Ard Biesheuvel <ardb@kernel.org>
Cc: kexec@lists.infradead.org
To: linux-arm-kernel@lists.infradead.org
---
 arch/arm64/Kconfig | 59 ++++++++++++++++++++++++++++++++++++++++++++++
 lib/Kconfig        |  3 +++
 2 files changed, 62 insertions(+)

diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index c5ccca26a408..58a65bdaeffa 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -1419,6 +1419,65 @@ config KEXEC_FILE
 	  for kernel and initramfs as opposed to list of segments as
 	  accepted by previous system call.
 
+menu "Decompress method for kexec file load"
+
+config KEXEC_DECOMPRESS_GZIP
+	bool "gzip"
+	depends on KEXEC_FILE
+	select DECOMPRESS_GZIP
+	select HAVE_KEXEC_DECOMPRESS
+	help
+	  Enable to load the zboot image compressed by gzip
+
+config KEXEC_DECOMPRESS_BZIP2
+	bool "bzip2"
+	depends on KEXEC_FILE
+	select DECOMPRESS_BZIP2
+	select HAVE_KEXEC_DECOMPRESS
+	help
+	  Enable to load the zboot image compressed by bzip2
+
+config KEXEC_DECOMPRESS_LZMA
+	bool "lzma"
+	depends on KEXEC_FILE
+	select DECOMPRESS_LZMA
+	select HAVE_KEXEC_DECOMPRESS
+	help
+	  Enable to load the zboot image compressed by lzma
+
+config KEXEC_DECOMPRESS_XZ
+	bool "xz"
+	depends on KEXEC_FILE
+	select DECOMPRESS_XZ
+	select HAVE_KEXEC_DECOMPRESS
+	help
+	  Enable to load the zboot image compressed by xz
+
+config KEXEC_DECOMPRESS_LZO
+	bool "lzo"
+	depends on KEXEC_FILE
+	select DECOMPRESS_LZO
+	select HAVE_KEXEC_DECOMPRESS
+	help
+	  Enable to load the zboot image compressed by lzo
+
+config KEXEC_DECOMPRESS_LZ4
+	bool "lz4"
+	depends on KEXEC_FILE
+	select DECOMPRESS_LZ4
+	select HAVE_KEXEC_DECOMPRESS
+	help
+	  Enable to load the zboot image compressed by lz4
+
+config KEXEC_DECOMPRESS_ZSTD
+	bool "zstd"
+	depends on KEXEC_FILE
+	select DECOMPRESS_ZSTD
+	select HAVE_KEXEC_DECOMPRESS
+	help
+	  Enable to load the zboot image compressed by zstd
+endmenu
+
 config KEXEC_SIG
 	bool "Verify kernel signature during kexec_file_load() syscall"
 	depends on KEXEC_FILE
diff --git a/lib/Kconfig b/lib/Kconfig
index ce2abffb9ed8..18ab33511ee1 100644
--- a/lib/Kconfig
+++ b/lib/Kconfig
@@ -304,6 +304,9 @@ config RANDOM32_SELFTEST
 #
 # compression support is select'ed if needed
 #
+config HAVE_KEXEC_DECOMPRESS
+	bool
+
 config 842_COMPRESS
 	select CRC32
 	tristate
-- 
2.31.1


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH 4/6] lib/decompress: Keep decompress routines based on selection

[Pingfan Liu]

At present, many decompressing routines in lib/decompress*.c are in
__section(".init.text"). But they are required to decompress the kernel
image when kexec file load compressed kernel.

To solve this issue, define 'INIT' conditional based on the macro
CONFIG_HAVE_KEXEC_DECOMPRESS. Also make lib/decompress.c adopt this way.

Signed-off-by: Pingfan Liu <kernelfans@gmail.com>
Cc: Ard Biesheuvel <ardb@kernel.org>
Cc: kexec@lists.infradead.org
To: linux-kernel@vger.kernel.org
---
 include/linux/decompress/mm.h | 9 ++++++++-
 lib/decompress.c              | 5 +++--
 2 files changed, 11 insertions(+), 3 deletions(-)

diff --git a/include/linux/decompress/mm.h b/include/linux/decompress/mm.h
index 9192986b1a73..33d8fd13a5c6 100644
--- a/include/linux/decompress/mm.h
+++ b/include/linux/decompress/mm.h
@@ -92,11 +92,18 @@ MALLOC_VISIBLE void free(void *where)
 #define large_malloc(a) vmalloc(a)
 #define large_free(a) vfree(a)
 
-#define INIT __init
 #define STATIC
 
 #include <linux/init.h>
 
+#ifndef CONFIG_HAVE_KEXEC_DECOMPRESS
+#define INIT __init
+#else
+#define INIT
+#undef __initconst
+#define __initconst
+#endif
+
 #endif /* STATIC */
 
 #endif /* DECOMPR_MM_H */
diff --git a/lib/decompress.c b/lib/decompress.c
index 8dd6f87e885f..33f097fe4b51 100644
--- a/lib/decompress.c
+++ b/lib/decompress.c
@@ -6,6 +6,7 @@
  */
 
 #include <linux/decompress/generic.h>
+#include <linux/decompress/mm.h>
 
 #include <linux/decompress/bunzip2.h>
 #include <linux/decompress/unlzma.h>
@@ -60,7 +61,7 @@ static const struct compress_format compressed_formats[] __initconst = {
 	{ {0, 0}, NULL, NULL }
 };
 
-decompress_fn __init decompress_method(const unsigned char *inbuf, long len,
+decompress_fn INIT decompress_method(const unsigned char *inbuf, long len,
 				const char **name)
 {
 	const struct compress_format *cf;
@@ -83,7 +84,7 @@ decompress_fn __init decompress_method(const unsigned char *inbuf, long len,
 	return cf->decompressor;
 }
 
-decompress_fn __init decompress_method_by_name(const unsigned char *name)
+decompress_fn INIT decompress_method_by_name(const unsigned char *name)
 {
 	const struct compress_format *cf;
 
-- 
2.31.1


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH 5/6] arm64: kexec: Introduce zboot image loader

[Pingfan Liu]

The EFI zboot kernel format can decompress and boot the vmlinux, but it
relies on the EFI service, which is not available when kexec jumps to
the new entry.

To tackle this issue, parsing zboot image and decompressing the Image.gz
part at the file loading time. But this way, in essential, the kexec
boots up Image.

As for decompression, it can be done either in the user space or the
kernel. But due to the signature verification in kernel, it should be
achieved in the kernel space.

Besides this, kexec faces a situation a little different from
efi_zboot_entry(), where the latter has knowledge of the system memory
through EFI services, while kexec can do it through the kernel's mm.

Signed-off-by: Pingfan Liu <kernelfans@gmail.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Will Deacon <will@kernel.org>
Cc: Nick Terrell <terrelln@fb.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Mimi Zohar <zohar@linux.ibm.com>
Cc: "Naveen N. Rao" <naveen.n.rao@linux.vnet.ibm.com>
Cc: Ard Biesheuvel <ardb@kernel.org>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Michal Suchanek <msuchanek@suse.de>
Cc: Baoquan He <bhe@redhat.com>
Cc: kexec@lists.infradead.org
To: linux-arm-kernel@lists.infradead.org
---
 arch/arm64/include/asm/kexec.h         |   2 +
 arch/arm64/kernel/Makefile             |   2 +-
 arch/arm64/kernel/kexec_zboot_image.c  | 186 +++++++++++++++++++++++++
 arch/arm64/kernel/machine_kexec.c      |   1 +
 arch/arm64/kernel/machine_kexec_file.c |   1 +
 include/linux/zboot.h                  |  26 ++++
 6 files changed, 217 insertions(+), 1 deletion(-)
 create mode 100644 arch/arm64/kernel/kexec_zboot_image.c
 create mode 100644 include/linux/zboot.h

diff --git a/arch/arm64/include/asm/kexec.h b/arch/arm64/include/asm/kexec.h
index 3f3d5a6830b7..8b820088323c 100644
--- a/arch/arm64/include/asm/kexec.h
+++ b/arch/arm64/include/asm/kexec.h
@@ -114,6 +114,7 @@ void arch_kexec_unprotect_crashkres(void);
 
 struct kimage_arch {
 	void *dtb;
+	void *decompressed_kernel;
 	phys_addr_t dtb_mem;
 	phys_addr_t kern_reloc;
 	phys_addr_t el2_vectors;
@@ -126,6 +127,7 @@ struct kimage_arch {
 
 #ifdef CONFIG_KEXEC_FILE
 extern const struct kexec_file_ops kexec_raw_ops;
+extern const struct kexec_file_ops kexec_zboot_ops;
 
 int arch_kimage_file_post_load_cleanup(struct kimage *image);
 #define arch_kimage_file_post_load_cleanup arch_kimage_file_post_load_cleanup
diff --git a/arch/arm64/kernel/Makefile b/arch/arm64/kernel/Makefile
index 99b52710606a..ec4d3c17ef70 100644
--- a/arch/arm64/kernel/Makefile
+++ b/arch/arm64/kernel/Makefile
@@ -63,7 +63,7 @@ obj-$(CONFIG_HIBERNATION)		+= hibernate.o hibernate-asm.o
 obj-$(CONFIG_ELF_CORE)			+= elfcore.o
 obj-$(CONFIG_KEXEC_CORE)		+= machine_kexec.o relocate_kernel.o	\
 					   cpu-reset.o
-obj-$(CONFIG_KEXEC_FILE)		+= machine_kexec_file.o kexec_raw_image.o
+obj-$(CONFIG_KEXEC_FILE)		+= machine_kexec_file.o kexec_raw_image.o kexec_zboot_image.o
 obj-$(CONFIG_ARM64_RELOC_TEST)		+= arm64-reloc-test.o
 arm64-reloc-test-y := reloc_test_core.o reloc_test_syms.o
 obj-$(CONFIG_CRASH_DUMP)		+= crash_dump.o
diff --git a/arch/arm64/kernel/kexec_zboot_image.c b/arch/arm64/kernel/kexec_zboot_image.c
new file mode 100644
index 000000000000..4629091666b7
--- /dev/null
+++ b/arch/arm64/kernel/kexec_zboot_image.c
@@ -0,0 +1,186 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Kexec zboot image loader.
+ * Code is based on kexec_raw_image.c
+ */
+
+#define pr_fmt(fmt)	"kexec_file(zboot): " fmt
+
+#include <linux/err.h>
+#include <linux/errno.h>
+#include <linux/kernel.h>
+#include <linux/kexec.h>
+#include <linux/pe.h>
+#include <linux/string.h>
+#include <asm/byteorder.h>
+#include <asm/cpufeature.h>
+#include <asm/image.h>
+#include <asm/memory.h>
+#include <linux/zboot.h>
+#include <linux/decompress/generic.h>
+
+static int zboot_image_probe(const char *kernel_buf, unsigned long kernel_len)
+{
+	struct zboot_image_header *h =
+		(struct zboot_image_header *)(kernel_buf);
+
+	if (!h || (kernel_len < sizeof(*h)))
+		return -EINVAL;
+
+	if (memcmp(&h->magic, (char *)MZ_MAGIC, sizeof(h->magic)))
+		return -EINVAL;
+	if (strncmp(h->zimg, "zimg", 4))
+		return -EINVAL;
+
+	return 0;
+}
+
+static void error(char *x)
+{
+	pr_err("%s\n", x);
+}
+
+static void *zboot_image_load(struct kimage *image,
+				char *kernel, unsigned long kernel_len,
+				char *initrd, unsigned long initrd_len,
+				char *cmdline, unsigned long cmdline_len)
+{
+	struct zboot_image_header *zh;
+	struct arm64_image_header *h;
+	char *decompressed_buf;
+	u32 sz;
+	long out_sz;
+	u64 flags, value;
+	bool be_image, be_kernel;
+	struct kexec_buf kbuf;
+	unsigned long text_offset, kernel_segment_number;
+	struct kexec_segment *kernel_segment;
+	int ret;
+	decompress_fn decompressor;
+
+	zh = (struct zboot_image_header *)kernel;
+	/*
+	 * zboot has SizeOfCode, SizeOfImage, SizeOfHeaders appended at the end. And
+	 * each occupies 4 bytes.
+	 */
+	sz = *(u32 *)(kernel + zh->gzdata_offset + zh->gzdata_size + 4);
+	out_sz = sz;
+	/* freed in machine_kexec_post_load() */
+	decompressed_buf = kmalloc(sz, GFP_KERNEL);
+	if (!decompressed_buf) {
+		pr_info("Can not get enough memory to decompress the zboot image\n");
+		return ERR_PTR(-ENOMEM);
+	}
+
+	decompressor = decompress_method_by_name(zh->comp_type);
+	if (!decompressor) {
+		pr_info("Invalid compress-format:%s\n", zh->comp_type);
+		ret = -EINVAL;
+		goto err;
+	}
+	ret = decompressor(kernel + zh->gzdata_offset, zh->gzdata_size, NULL, NULL,
+			   (void *)decompressed_buf, &out_sz, error);
+
+	if (ret) {
+		pr_info("Fail to decompress the zboot image\n");
+		ret = -EINVAL;
+		goto err;
+	}
+
+	h = (struct arm64_image_header *)decompressed_buf;
+	if (!h->image_size) {
+		kfree(decompressed_buf);
+		ret = -EINVAL;
+		goto err;
+	}
+
+	/* Check cpu features */
+	flags = le64_to_cpu(h->flags);
+	be_image = arm64_image_flag_field(flags, ARM64_IMAGE_FLAG_BE);
+	be_kernel = IS_ENABLED(CONFIG_CPU_BIG_ENDIAN);
+	if ((be_image != be_kernel) && !system_supports_mixed_endian()) {
+		ret = -EINVAL;
+		goto err;
+	}
+
+	value = arm64_image_flag_field(flags, ARM64_IMAGE_FLAG_PAGE_SIZE);
+	if (((value == ARM64_IMAGE_FLAG_PAGE_SIZE_4K) &&
+			!system_supports_4kb_granule()) ||
+	    ((value == ARM64_IMAGE_FLAG_PAGE_SIZE_64K) &&
+			!system_supports_64kb_granule()) ||
+	    ((value == ARM64_IMAGE_FLAG_PAGE_SIZE_16K) &&
+			!system_supports_16kb_granule())) {
+		ret = -EINVAL;
+		goto err;
+	}
+
+	/* Load the kernel */
+	kbuf.image = image;
+	kbuf.buf_min = 0;
+	kbuf.buf_max = ULONG_MAX;
+	kbuf.top_down = false;
+
+	kbuf.buffer = decompressed_buf;
+	kbuf.bufsz = sz;
+	kbuf.mem = KEXEC_BUF_MEM_UNKNOWN;
+	kbuf.memsz = le64_to_cpu(h->image_size);
+	text_offset = le64_to_cpu(h->text_offset);
+	kbuf.buf_align = MIN_KIMG_ALIGN;
+
+	/* Adjust kernel segment with TEXT_OFFSET */
+	kbuf.memsz += text_offset;
+
+	kernel_segment_number = image->nr_segments;
+
+	/*
+	 * The location of the kernel segment may make it impossible to satisfy
+	 * the other segment requirements, so we try repeatedly to find a
+	 * location that will work.
+	 */
+	while ((ret = kexec_add_buffer(&kbuf)) == 0) {
+		/* Try to load additional data */
+		kernel_segment = &image->segment[kernel_segment_number];
+		ret = load_other_segments(image, kernel_segment->mem,
+					  kernel_segment->memsz, initrd,
+					  initrd_len, cmdline);
+		if (!ret)
+			break;
+
+		/*
+		 * We couldn't find space for the other segments; erase the
+		 * kernel segment and try the next available hole.
+		 */
+		image->nr_segments -= 1;
+		kbuf.buf_min = kernel_segment->mem + kernel_segment->memsz;
+		kbuf.mem = KEXEC_BUF_MEM_UNKNOWN;
+	}
+
+	if (ret) {
+		pr_err("Could not find any suitable kernel location!");
+		goto err;
+	}
+
+	kernel_segment = &image->segment[kernel_segment_number];
+	kernel_segment->mem += text_offset;
+	kernel_segment->memsz -= text_offset;
+	image->start = kernel_segment->mem;
+	image->arch.decompressed_kernel = decompressed_buf;
+
+	pr_debug("Loaded kernel at 0x%lx bufsz=0x%lx memsz=0x%lx\n",
+				kernel_segment->mem, kbuf.bufsz,
+				kernel_segment->memsz);
+
+	return NULL;
+
+err:
+	kfree(decompressed_buf);
+	return ERR_PTR(ret);
+}
+
+const struct kexec_file_ops kexec_zboot_ops = {
+	.probe = zboot_image_probe,
+	.load = zboot_image_load,
+#ifdef CONFIG_KEXEC_IMAGE_VERIFY_SIG
+	.verify_sig = kexec_kernel_verify_pe_sig,
+#endif
+};
diff --git a/arch/arm64/kernel/machine_kexec.c b/arch/arm64/kernel/machine_kexec.c
index ce3d40120f72..866c1c27a9ea 100644
--- a/arch/arm64/kernel/machine_kexec.c
+++ b/arch/arm64/kernel/machine_kexec.c
@@ -166,6 +166,7 @@ int machine_kexec_post_load(struct kimage *kimage)
 	icache_inval_pou((uintptr_t)reloc_code,
 			 (uintptr_t)reloc_code + reloc_size);
 	kexec_image_info(kimage);
+	kfree(kimage->arch.decompressed_kernel);
 
 	return 0;
 }
diff --git a/arch/arm64/kernel/machine_kexec_file.c b/arch/arm64/kernel/machine_kexec_file.c
index 0738020507d1..02d7e4004cfb 100644
--- a/arch/arm64/kernel/machine_kexec_file.c
+++ b/arch/arm64/kernel/machine_kexec_file.c
@@ -24,6 +24,7 @@
 
 const struct kexec_file_ops * const kexec_file_loaders[] = {
 	&kexec_raw_ops,
+	&kexec_zboot_ops,
 	NULL
 };
 
diff --git a/include/linux/zboot.h b/include/linux/zboot.h
new file mode 100644
index 000000000000..abefcb92e1ad
--- /dev/null
+++ b/include/linux/zboot.h
@@ -0,0 +1,26 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+#ifndef ZBOOT_H
+#define ZBOOT_H
+
+struct zboot_image_header {
+	union {
+		struct {
+			u32 magic;
+			/* image type, .ascii "zimg" */
+			char zimg[4];
+			s32 gzdata_offset;
+			s32 gzdata_size;
+			s32 reserved[2];
+			/* compression type, .asciz */
+			char comp_type[];
+		};
+		struct {
+			char pad[56];
+		};
+	};
+	/* 0x818223cd */
+	u32 linux_pe_magic;
+	s32 pe_header_offset;
+} __packed;
+
+#endif
-- 
2.31.1


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH 6/6] init/Kconfig: Select decompressing method if compressing kernel

[Pingfan Liu]

If choosing an EFI_ZBOOT image, the corresponding decompressing method
should be selected so that kexec can load that zboot image.

This can be achieved when "Kernel compression mode" is determined.

Signed-off-by: Pingfan Liu <kernelfans@gmail.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Nick Desaulniers <ndesaulniers@google.com>
Cc: Masahiro Yamada <masahiroy@kernel.org>
Cc: Johannes Weiner <hannes@cmpxchg.org>
Cc: Nathan Chancellor <nathan@kernel.org>
Cc: Miguel Ojeda <ojeda@kernel.org>
Cc: Masami Hiramatsu <mhiramat@kernel.org>
Cc: Ard Biesheuvel <ardb@kernel.org>
Cc: kexec@lists.infradead.org
To: linux-kernel@vger.kernel.org
---
 init/Kconfig | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/init/Kconfig b/init/Kconfig
index 44e90b28a30f..046724208645 100644
--- a/init/Kconfig
+++ b/init/Kconfig
@@ -269,6 +269,7 @@ choice
 config KERNEL_GZIP
 	bool "Gzip"
 	depends on HAVE_KERNEL_GZIP
+	select KEXEC_DECOMPRESS_GZIP if KEXEC_FILE && EFI_ZBOOT
 	help
 	  The old and tried gzip compression. It provides a good balance
 	  between compression ratio and decompression speed.
@@ -276,6 +277,7 @@ config KERNEL_GZIP
 config KERNEL_BZIP2
 	bool "Bzip2"
 	depends on HAVE_KERNEL_BZIP2
+	select KEXEC_DECOMPRESS_BZIP2 if KEXEC_FILE && EFI_ZBOOT
 	help
 	  Its compression ratio and speed is intermediate.
 	  Decompression speed is slowest among the choices.  The kernel
@@ -286,6 +288,7 @@ config KERNEL_BZIP2
 config KERNEL_LZMA
 	bool "LZMA"
 	depends on HAVE_KERNEL_LZMA
+	select KEXEC_DECOMPRESS_LZMA if KEXEC_FILE && EFI_ZBOOT
 	help
 	  This compression algorithm's ratio is best.  Decompression speed
 	  is between gzip and bzip2.  Compression is slowest.
@@ -294,6 +297,7 @@ config KERNEL_LZMA
 config KERNEL_XZ
 	bool "XZ"
 	depends on HAVE_KERNEL_XZ
+	select KEXEC_DECOMPRESS_XZ if KEXEC_FILE && EFI_ZBOOT
 	help
 	  XZ uses the LZMA2 algorithm and instruction set specific
 	  BCJ filters which can improve compression ratio of executable
@@ -309,6 +313,7 @@ config KERNEL_XZ
 config KERNEL_LZO
 	bool "LZO"
 	depends on HAVE_KERNEL_LZO
+	select KEXEC_DECOMPRESS_LZO if KEXEC_FILE && EFI_ZBOOT
 	help
 	  Its compression ratio is the poorest among the choices. The kernel
 	  size is about 10% bigger than gzip; however its speed
@@ -317,6 +322,7 @@ config KERNEL_LZO
 config KERNEL_LZ4
 	bool "LZ4"
 	depends on HAVE_KERNEL_LZ4
+	select KEXEC_DECOMPRESS_LZ4 if KEXEC_FILE && EFI_ZBOOT
 	help
 	  LZ4 is an LZ77-type compressor with a fixed, byte-oriented encoding.
 	  A preliminary version of LZ4 de/compression tool is available at
@@ -329,6 +335,7 @@ config KERNEL_LZ4
 config KERNEL_ZSTD
 	bool "ZSTD"
 	depends on HAVE_KERNEL_ZSTD
+	select KEXEC_DECOMPRESS_ZSTD if KEXEC_FILE && EFI_ZBOOT
 	help
 	  ZSTD is a compression algorithm targeting intermediate compression
 	  with fast decompression speed. It will compress better than GZIP and
-- 
2.31.1


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH 0/6] arm64: make kexec_file able to load zboot image

[Ard Biesheuvel]

(cc Mark)

Hello Pingfan,

Thanks for working on this.

On Mon, 6 Mar 2023 at 04:03, Pingfan Liu <kernelfans@gmail.com> wrote:
>
> After introducing zboot image, kexec_file can not load and jump to the
> new style image. Hence it demands a method to load the new kernel.
>
> The crux of the problem lies in when and how to decompress the Image.gz.
> There are three possible courses to take: -1. in user space, but hard to
> achieve due to the signature verification inside the kernel.

That depends. The EFI zboot image encapsulates another PE/COFF image,
which could be signed as well.

So there are at least three other options here:
- sign the encapsulated image with the same key as the zboot image
- sign the encapsulated image with a key that is only valid for kexec boot
- sign the encapsulated image with an ephemeral key that is only valid
for a kexec'ing an image that was produced by the same kernel build

>  -2. at the
> boot time, let the efi_zboot_entry() handles it, which means a simulated
> EFI service should be provided to that entry, especially about how to be
> aware of the memory layout.

This is actually an idea I intend to explore: with the EFI runtime
services regions mapped 1:1, it wouldn't be too hard to implement a
minimal environment that can run the zboot image under the previous
kernel up to the point where it call ExitBootServices(), after which
kexec() would take over.

>  -3. in kernel space, during the file load
> of the zboot image. At that point, the kernel masters the whole memory
> information, and easily allocates a suitable memory for the decompressed
> kernel image. (I think this is similar to what grub does today).
>

GRUB just calls LoadImage(), and the decompression code runs in the EFI context.

> The core of this series is [5/6].  [3,6/6] handles the config option.
> The assumption of [3/6] is kexec_file_load is independent of zboot,
> especially it can load kernel images compressed with different
> compression method.  [6/6] is if EFI_ZBOOT, the corresponding
> decompression method should be included.
>
>
> Cc: Catalin Marinas <catalin.marinas@arm.com>
> Cc: Will Deacon <will@kernel.org>
> Cc: Andrew Morton <akpm@linux-foundation.org>
> Cc: Ard Biesheuvel <ardb@kernel.org>
> Cc: kexec@lists.infradead.org
> To: linux-arm-kernel@lists.infradead.org
> To: linux-kernel@vger.kernel.org
>
> Pingfan Liu (6):
>   arm64: kexec: Rename kexec_image.c to kexec_raw_image.c
>   lib/decompress: Introduce decompress_method_by_name()
>   arm64: Kconfig: Pick decompressing method for kexec file load
>   lib/decompress: Keep decompress routines based on selection
>   arm64: kexec: Introduce zboot image loader
>   init/Kconfig: Select decompressing method if compressing kernel
>
>  arch/arm64/Kconfig                            |  59 ++++++
>  arch/arm64/include/asm/kexec.h                |   4 +-
>  arch/arm64/kernel/Makefile                    |   2 +-
>  .../{kexec_image.c => kexec_raw_image.c}      |   2 +-
>  arch/arm64/kernel/kexec_zboot_image.c         | 186 ++++++++++++++++++
>  arch/arm64/kernel/machine_kexec.c             |   1 +
>  arch/arm64/kernel/machine_kexec_file.c        |   3 +-
>  include/linux/decompress/generic.h            |   2 +
>  include/linux/decompress/mm.h                 |   9 +-
>  include/linux/zboot.h                         |  26 +++
>  init/Kconfig                                  |   7 +
>  lib/Kconfig                                   |   3 +
>  lib/decompress.c                              |  17 +-
>  13 files changed, 314 insertions(+), 7 deletions(-)
>  rename arch/arm64/kernel/{kexec_image.c => kexec_raw_image.c} (98%)
>  create mode 100644 arch/arm64/kernel/kexec_zboot_image.c
>  create mode 100644 include/linux/zboot.h
>
> --
> 2.31.1
>

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH 0/6] arm64: make kexec_file able to load zboot image

[Pingfan Liu]

Hi Ard,

Thanks for sharing your idea. Please see the comment.

On Mon, Mar 06, 2023 at 09:08:03AM +0100, Ard Biesheuvel wrote:
> (cc Mark)
> 
> Hello Pingfan,
> 
> Thanks for working on this.
> 
> On Mon, 6 Mar 2023 at 04:03, Pingfan Liu <kernelfans@gmail.com> wrote:
> >
> > After introducing zboot image, kexec_file can not load and jump to the
> > new style image. Hence it demands a method to load the new kernel.
> >
> > The crux of the problem lies in when and how to decompress the Image.gz.
> > There are three possible courses to take: -1. in user space, but hard to
> > achieve due to the signature verification inside the kernel.
> 
> That depends. The EFI zboot image encapsulates another PE/COFF image,
> which could be signed as well.
> 
> So there are at least three other options here:
> - sign the encapsulated image with the same key as the zboot image
> - sign the encapsulated image with a key that is only valid for kexec boot
> - sign the encapsulated image with an ephemeral key that is only valid
> for a kexec'ing an image that was produced by the same kernel build
> 
> >  -2. at the
> > boot time, let the efi_zboot_entry() handles it, which means a simulated
> > EFI service should be provided to that entry, especially about how to be
> > aware of the memory layout.
> 
> This is actually an idea I intend to explore: with the EFI runtime
> services regions mapped 1:1, it wouldn't be too hard to implement a
> minimal environment that can run the zboot image under the previous

The idea of the minimal environment lools amazing. After digging
more deeply into it, I think it means to implement most of the function
members in efi_boot_services, besides that, some UEFI protocols due to
the reference of efi_call_proto(). So a clear boundary between zboot and
its dependent EFI service is demanded before the work.

> kernel up to the point where it call ExitBootServices(), after which
> kexec() would take over.
> 

IIUC, after kexec switches to efi_zboot_entry(), it will not return,
right?

> >  -3. in kernel space, during the file load
> > of the zboot image. At that point, the kernel masters the whole memory
> > information, and easily allocates a suitable memory for the decompressed
> > kernel image. (I think this is similar to what grub does today).
> >
> 
> GRUB just calls LoadImage(), and the decompression code runs in the EFI context.
> 

Ah, thanks for the correcting. I had made an wrong assumption of grub
based on [1], from which, I thought that grub is the case "For
compatibility with non-EFI loaders, the payload can be decompressed and
executed by the loader as well, provided that the loader implements the
decompression algorithm and that non-EFI boot is supported by the
encapsulated image" 


[1]: https://www.phoronix.com/news/Linux-6.1-Generic-EFI-Zboot


Eager to find a solution to kexec a zboot image. Hope it will come soon.


Thanks,

	Pingfan
> > The core of this series is [5/6].  [3,6/6] handles the config option.
> > The assumption of [3/6] is kexec_file_load is independent of zboot,
> > especially it can load kernel images compressed with different
> > compression method.  [6/6] is if EFI_ZBOOT, the corresponding
> > decompression method should be included.
> >
> >
> > Cc: Catalin Marinas <catalin.marinas@arm.com>
> > Cc: Will Deacon <will@kernel.org>
> > Cc: Andrew Morton <akpm@linux-foundation.org>
> > Cc: Ard Biesheuvel <ardb@kernel.org>
> > Cc: kexec@lists.infradead.org
> > To: linux-arm-kernel@lists.infradead.org
> > To: linux-kernel@vger.kernel.org
> >
> > Pingfan Liu (6):
> >   arm64: kexec: Rename kexec_image.c to kexec_raw_image.c
> >   lib/decompress: Introduce decompress_method_by_name()
> >   arm64: Kconfig: Pick decompressing method for kexec file load
> >   lib/decompress: Keep decompress routines based on selection
> >   arm64: kexec: Introduce zboot image loader
> >   init/Kconfig: Select decompressing method if compressing kernel
> >
> >  arch/arm64/Kconfig                            |  59 ++++++
> >  arch/arm64/include/asm/kexec.h                |   4 +-
> >  arch/arm64/kernel/Makefile                    |   2 +-
> >  .../{kexec_image.c => kexec_raw_image.c}      |   2 +-
> >  arch/arm64/kernel/kexec_zboot_image.c         | 186 ++++++++++++++++++
> >  arch/arm64/kernel/machine_kexec.c             |   1 +
> >  arch/arm64/kernel/machine_kexec_file.c        |   3 +-
> >  include/linux/decompress/generic.h            |   2 +
> >  include/linux/decompress/mm.h                 |   9 +-
> >  include/linux/zboot.h                         |  26 +++
> >  init/Kconfig                                  |   7 +
> >  lib/Kconfig                                   |   3 +
> >  lib/decompress.c                              |  17 +-
> >  13 files changed, 314 insertions(+), 7 deletions(-)
> >  rename arch/arm64/kernel/{kexec_image.c => kexec_raw_image.c} (98%)
> >  create mode 100644 arch/arm64/kernel/kexec_zboot_image.c
> >  create mode 100644 include/linux/zboot.h
> >
> > --
> > 2.31.1
> >

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH 0/6] arm64: make kexec_file able to load zboot image

[Pingfan Liu]

On Tue, Mar 07, 2023 at 04:08:55PM +0800, Pingfan Liu wrote:
> Hi Ard,
> 
> Thanks for sharing your idea. Please see the comment.
> 
> On Mon, Mar 06, 2023 at 09:08:03AM +0100, Ard Biesheuvel wrote:
> > (cc Mark)
> > 
> > Hello Pingfan,
> > 
> > Thanks for working on this.
> > 
> > On Mon, 6 Mar 2023 at 04:03, Pingfan Liu <kernelfans@gmail.com> wrote:
> > >
> > > After introducing zboot image, kexec_file can not load and jump to the
> > > new style image. Hence it demands a method to load the new kernel.
> > >
> > > The crux of the problem lies in when and how to decompress the Image.gz.
> > > There are three possible courses to take: -1. in user space, but hard to
> > > achieve due to the signature verification inside the kernel.
> > 
> > That depends. The EFI zboot image encapsulates another PE/COFF image,
> > which could be signed as well.
> > 
> > So there are at least three other options here:
> > - sign the encapsulated image with the same key as the zboot image
> > - sign the encapsulated image with a key that is only valid for kexec boot
> > - sign the encapsulated image with an ephemeral key that is only valid
> > for a kexec'ing an image that was produced by the same kernel build
> > 
> > >  -2. at the
> > > boot time, let the efi_zboot_entry() handles it, which means a simulated
> > > EFI service should be provided to that entry, especially about how to be
> > > aware of the memory layout.
> > 
> > This is actually an idea I intend to explore: with the EFI runtime
> > services regions mapped 1:1, it wouldn't be too hard to implement a
> > minimal environment that can run the zboot image under the previous
> 
> The idea of the minimal environment lools amazing. After digging
> more deeply into it, I think it means to implement most of the function
> members in efi_boot_services, besides that, some UEFI protocols due to
> the reference of efi_call_proto(). So a clear boundary between zboot and
> its dependent EFI service is demanded before the work.
> 

Looking deeper into it. This approach may be splitted into the following
chunks:
-1. Estimation the memory demanded by the decompression of zboot, which
roughly includes the size of Image, the size of the emulated service and
the stack used by zboot. Finally we need a kexec_add_buffer() for this
range.

-2. The emulated EFI services and some initial data such as the physical
address of dtb, the usable memory start address and size should be set
by kexec_purgatory_get_set_symbol()

-3. Set up an identity mapping of the usable memory by zboot, prepare
stack and turn on MMU at the last point just before 'br efi_zboot_entry'
in relocate_kernel.S, which means relocate_kernel.S should support two
kinds of payload.

-4. For efi_zboot_entry(), if jumping from kexec, limit its requirement
to only a few boot services: e.g. allocate_pages, allocate_pool. So the
emulated services can be deduced.

> > kernel up to the point where it call ExitBootServices(), after which
> > kexec() would take over.
> > 
> 
> IIUC, after kexec switches to efi_zboot_entry(), it will not return,
> right?
> 

I have this assumption because letting the control path switch between
kernel and non-kernel code is not a good idea.


Thanks,

Pingfan

> > >  -3. in kernel space, during the file load
> > > of the zboot image. At that point, the kernel masters the whole memory
> > > information, and easily allocates a suitable memory for the decompressed
> > > kernel image. (I think this is similar to what grub does today).
> > >
> > 
> > GRUB just calls LoadImage(), and the decompression code runs in the EFI context.
> > 
> 
> Ah, thanks for the correcting. I had made an wrong assumption of grub
> based on [1], from which, I thought that grub is the case "For
> compatibility with non-EFI loaders, the payload can be decompressed and
> executed by the loader as well, provided that the loader implements the
> decompression algorithm and that non-EFI boot is supported by the
> encapsulated image" 
> 
> 
> [1]: https://www.phoronix.com/news/Linux-6.1-Generic-EFI-Zboot
> 
> 
> Eager to find a solution to kexec a zboot image. Hope it will come soon.
> 
> 
> Thanks,
> 
> 	Pingfan
> > > The core of this series is [5/6].  [3,6/6] handles the config option.
> > > The assumption of [3/6] is kexec_file_load is independent of zboot,
> > > especially it can load kernel images compressed with different
> > > compression method.  [6/6] is if EFI_ZBOOT, the corresponding
> > > decompression method should be included.
> > >
> > >
> > > Cc: Catalin Marinas <catalin.marinas@arm.com>
> > > Cc: Will Deacon <will@kernel.org>
> > > Cc: Andrew Morton <akpm@linux-foundation.org>
> > > Cc: Ard Biesheuvel <ardb@kernel.org>
> > > Cc: kexec@lists.infradead.org
> > > To: linux-arm-kernel@lists.infradead.org
> > > To: linux-kernel@vger.kernel.org
> > >
> > > Pingfan Liu (6):
> > >   arm64: kexec: Rename kexec_image.c to kexec_raw_image.c
> > >   lib/decompress: Introduce decompress_method_by_name()
> > >   arm64: Kconfig: Pick decompressing method for kexec file load
> > >   lib/decompress: Keep decompress routines based on selection
> > >   arm64: kexec: Introduce zboot image loader
> > >   init/Kconfig: Select decompressing method if compressing kernel
> > >
> > >  arch/arm64/Kconfig                            |  59 ++++++
> > >  arch/arm64/include/asm/kexec.h                |   4 +-
> > >  arch/arm64/kernel/Makefile                    |   2 +-
> > >  .../{kexec_image.c => kexec_raw_image.c}      |   2 +-
> > >  arch/arm64/kernel/kexec_zboot_image.c         | 186 ++++++++++++++++++
> > >  arch/arm64/kernel/machine_kexec.c             |   1 +
> > >  arch/arm64/kernel/machine_kexec_file.c        |   3 +-
> > >  include/linux/decompress/generic.h            |   2 +
> > >  include/linux/decompress/mm.h                 |   9 +-
> > >  include/linux/zboot.h                         |  26 +++
> > >  init/Kconfig                                  |   7 +
> > >  lib/Kconfig                                   |   3 +
> > >  lib/decompress.c                              |  17 +-
> > >  13 files changed, 314 insertions(+), 7 deletions(-)
> > >  rename arch/arm64/kernel/{kexec_image.c => kexec_raw_image.c} (98%)
> > >  create mode 100644 arch/arm64/kernel/kexec_zboot_image.c
> > >  create mode 100644 include/linux/zboot.h
> > >
> > > --
> > > 2.31.1
> > >

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH 0/6] arm64: make kexec_file able to load zboot image

[Naresh Kamboju]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=y, Size: 844 bytes --]

Results from Linaro’s test farm.

> After introducing zboot image, kexec_file can not load and jump to the
> new style image. Hence it demands a method to load the new kernel.

...

This patch set build and boot tested on arm, arm64 and FVP.

> Cc: Catalin Marinas <catalin.marinas@arm.com>
> Cc: Will Deacon <will@kernel.org>
> Cc: Andrew Morton <akpm@linux-foundation.org>
> Cc: Ard Biesheuvel <ardb@kernel.org>
> Cc: kexec@lists.infradead.org
> To: linux-arm-kernel@lists.infradead.org
> To: linux-kernel@vger.kernel.org

Tested-by: Linux Kernel Functional Testing <lkft@linaro.org>

links to test results,
 - https://qa-reports.linaro.org/~anders.roxell/linux-mainline-patches/build/lore_kernel_org_linux-arm-kernel_20230306030305_15595-1-kernelfans_gmail_com/?failures_only=false#!#test-results


--
Linaro LKFT
https://lkft.linaro.org


[-- Attachment #2: Type: text/plain, Size: 176 bytes --]

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH 0/6] arm64: make kexec_file able to load zboot image

[Dave Young]

On Fri, 10 Mar 2023 at 12:18, Pingfan Liu <kernelfans@gmail.com> wrote:
>
> On Tue, Mar 07, 2023 at 04:08:55PM +0800, Pingfan Liu wrote:
> > Hi Ard,
> >
> > Thanks for sharing your idea. Please see the comment.
> >
> > On Mon, Mar 06, 2023 at 09:08:03AM +0100, Ard Biesheuvel wrote:
> > > (cc Mark)
> > >
> > > Hello Pingfan,
> > >
> > > Thanks for working on this.
> > >
> > > On Mon, 6 Mar 2023 at 04:03, Pingfan Liu <kernelfans@gmail.com> wrote:
> > > >
> > > > After introducing zboot image, kexec_file can not load and jump to the
> > > > new style image. Hence it demands a method to load the new kernel.
> > > >
> > > > The crux of the problem lies in when and how to decompress the Image.gz.
> > > > There are three possible courses to take: -1. in user space, but hard to
> > > > achieve due to the signature verification inside the kernel.
> > >
> > > That depends. The EFI zboot image encapsulates another PE/COFF image,
> > > which could be signed as well.
> > >
> > > So there are at least three other options here:
> > > - sign the encapsulated image with the same key as the zboot image
> > > - sign the encapsulated image with a key that is only valid for kexec boot
> > > - sign the encapsulated image with an ephemeral key that is only valid
> > > for a kexec'ing an image that was produced by the same kernel build
> > >
> > > >  -2. at the
> > > > boot time, let the efi_zboot_entry() handles it, which means a simulated
> > > > EFI service should be provided to that entry, especially about how to be
> > > > aware of the memory layout.
> > >
> > > This is actually an idea I intend to explore: with the EFI runtime
> > > services regions mapped 1:1, it wouldn't be too hard to implement a
> > > minimal environment that can run the zboot image under the previous
> >
> > The idea of the minimal environment lools amazing. After digging
> > more deeply into it, I think it means to implement most of the function
> > members in efi_boot_services, besides that, some UEFI protocols due to
> > the reference of efi_call_proto(). So a clear boundary between zboot and
> > its dependent EFI service is demanded before the work.
> >
>
> Looking deeper into it. This approach may be splitted into the following
> chunks:
> -1. Estimation the memory demanded by the decompression of zboot, which
> roughly includes the size of Image, the size of the emulated service and
> the stack used by zboot. Finally we need a kexec_add_buffer() for this
> range.
>
> -2. The emulated EFI services and some initial data such as the physical
> address of dtb, the usable memory start address and size should be set
> by kexec_purgatory_get_set_symbol()
>
> -3. Set up an identity mapping of the usable memory by zboot, prepare
> stack and turn on MMU at the last point just before 'br efi_zboot_entry'
> in relocate_kernel.S, which means relocate_kernel.S should support two
> kinds of payload.
>
> -4. For efi_zboot_entry(), if jumping from kexec, limit its requirement
> to only a few boot services: e.g. allocate_pages, allocate_pool. So the
> emulated services can be deduced.

Hi Pingfan,

I'm not sure how hard it will be although Ard thinks it could be
doable.  If it is not easy I suspect it is not worth the effort.

For your current series,  my suggestion is you can try to move the
major code in the generic code path in kernel/kexec_file.c and keep
the arch code minimum so that in the future other arches can avoid
redundant code.

Otherwise a fallback solution could be using the same key to sign both
the zboot image and the internal kernel image like below:
1. sign the kernel with the same key twice (kernel image and zboot
image) in distro kernel
2. introduce a kconfig in mainline to sign the kernel image with an
ephemeral key same to kernel modules.  Distro can disable the config
option. (in this way kexec can only load the same kernel, it is not
useful if people want to load older/newer kernels)
3. patch kexec-tools to decompress the zboot image and load the kernel image


>
> > > kernel up to the point where it call ExitBootServices(), after which
> > > kexec() would take over.
> > >
> >
> > IIUC, after kexec switches to efi_zboot_entry(), it will not return,
> > right?
> >
>
> I have this assumption because letting the control path switch between
> kernel and non-kernel code is not a good idea.
>
>
> Thanks,
>
> Pingfan
>
> > > >  -3. in kernel space, during the file load
> > > > of the zboot image. At that point, the kernel masters the whole memory
> > > > information, and easily allocates a suitable memory for the decompressed
> > > > kernel image. (I think this is similar to what grub does today).
> > > >
> > >
> > > GRUB just calls LoadImage(), and the decompression code runs in the EFI context.
> > >
> >
> > Ah, thanks for the correcting. I had made an wrong assumption of grub
> > based on [1], from which, I thought that grub is the case "For
> > compatibility with non-EFI loaders, the payload can be decompressed and
> > executed by the loader as well, provided that the loader implements the
> > decompression algorithm and that non-EFI boot is supported by the
> > encapsulated image"
> >
> >
> > [1]: https://www.phoronix.com/news/Linux-6.1-Generic-EFI-Zboot
> >
> >
> > Eager to find a solution to kexec a zboot image. Hope it will come soon.
> >
> >
> > Thanks,
> >
> >       Pingfan
> > > > The core of this series is [5/6].  [3,6/6] handles the config option.
> > > > The assumption of [3/6] is kexec_file_load is independent of zboot,
> > > > especially it can load kernel images compressed with different
> > > > compression method.  [6/6] is if EFI_ZBOOT, the corresponding
> > > > decompression method should be included.
> > > >
> > > >
> > > > Cc: Catalin Marinas <catalin.marinas@arm.com>
> > > > Cc: Will Deacon <will@kernel.org>
> > > > Cc: Andrew Morton <akpm@linux-foundation.org>
> > > > Cc: Ard Biesheuvel <ardb@kernel.org>
> > > > Cc: kexec@lists.infradead.org
> > > > To: linux-arm-kernel@lists.infradead.org
> > > > To: linux-kernel@vger.kernel.org
> > > >
> > > > Pingfan Liu (6):
> > > >   arm64: kexec: Rename kexec_image.c to kexec_raw_image.c
> > > >   lib/decompress: Introduce decompress_method_by_name()
> > > >   arm64: Kconfig: Pick decompressing method for kexec file load
> > > >   lib/decompress: Keep decompress routines based on selection
> > > >   arm64: kexec: Introduce zboot image loader
> > > >   init/Kconfig: Select decompressing method if compressing kernel
> > > >
> > > >  arch/arm64/Kconfig                            |  59 ++++++
> > > >  arch/arm64/include/asm/kexec.h                |   4 +-
> > > >  arch/arm64/kernel/Makefile                    |   2 +-
> > > >  .../{kexec_image.c => kexec_raw_image.c}      |   2 +-
> > > >  arch/arm64/kernel/kexec_zboot_image.c         | 186 ++++++++++++++++++
> > > >  arch/arm64/kernel/machine_kexec.c             |   1 +
> > > >  arch/arm64/kernel/machine_kexec_file.c        |   3 +-
> > > >  include/linux/decompress/generic.h            |   2 +
> > > >  include/linux/decompress/mm.h                 |   9 +-
> > > >  include/linux/zboot.h                         |  26 +++
> > > >  init/Kconfig                                  |   7 +
> > > >  lib/Kconfig                                   |   3 +
> > > >  lib/decompress.c                              |  17 +-
> > > >  13 files changed, 314 insertions(+), 7 deletions(-)
> > > >  rename arch/arm64/kernel/{kexec_image.c => kexec_raw_image.c} (98%)
> > > >  create mode 100644 arch/arm64/kernel/kexec_zboot_image.c
> > > >  create mode 100644 include/linux/zboot.h
> > > >
> > > > --
> > > > 2.31.1
> > > >
>
> _______________________________________________
> kexec mailing list
> kexec@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/kexec
>


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH 0/6] arm64: make kexec_file able to load zboot image

[Pingfan Liu]

Hi Dave,

Thanks for your suggestion. Please see the comment inlined.

On Wed, Mar 22, 2023 at 11:44:52AM +0800, Dave Young wrote:
> On Fri, 10 Mar 2023 at 12:18, Pingfan Liu <kernelfans@gmail.com> wrote:
> >
> > On Tue, Mar 07, 2023 at 04:08:55PM +0800, Pingfan Liu wrote:
> > > Hi Ard,
> > >
> > > Thanks for sharing your idea. Please see the comment.
> > >
> > > On Mon, Mar 06, 2023 at 09:08:03AM +0100, Ard Biesheuvel wrote:
> > > > (cc Mark)
> > > >
> > > > Hello Pingfan,
> > > >
> > > > Thanks for working on this.
> > > >
> > > > On Mon, 6 Mar 2023 at 04:03, Pingfan Liu <kernelfans@gmail.com> wrote:
> > > > >
> > > > > After introducing zboot image, kexec_file can not load and jump to the
> > > > > new style image. Hence it demands a method to load the new kernel.
> > > > >
> > > > > The crux of the problem lies in when and how to decompress the Image.gz.
> > > > > There are three possible courses to take: -1. in user space, but hard to
> > > > > achieve due to the signature verification inside the kernel.
> > > >
> > > > That depends. The EFI zboot image encapsulates another PE/COFF image,
> > > > which could be signed as well.
> > > >
> > > > So there are at least three other options here:
> > > > - sign the encapsulated image with the same key as the zboot image
> > > > - sign the encapsulated image with a key that is only valid for kexec boot
> > > > - sign the encapsulated image with an ephemeral key that is only valid
> > > > for a kexec'ing an image that was produced by the same kernel build
> > > >
> > > > >  -2. at the
> > > > > boot time, let the efi_zboot_entry() handles it, which means a simulated
> > > > > EFI service should be provided to that entry, especially about how to be
> > > > > aware of the memory layout.
> > > >
> > > > This is actually an idea I intend to explore: with the EFI runtime
> > > > services regions mapped 1:1, it wouldn't be too hard to implement a
> > > > minimal environment that can run the zboot image under the previous
> > >
> > > The idea of the minimal environment lools amazing. After digging
> > > more deeply into it, I think it means to implement most of the function
> > > members in efi_boot_services, besides that, some UEFI protocols due to
> > > the reference of efi_call_proto(). So a clear boundary between zboot and
> > > its dependent EFI service is demanded before the work.
> > >
> >
> > Looking deeper into it. This approach may be splitted into the following
> > chunks:
> > -1. Estimation the memory demanded by the decompression of zboot, which
> > roughly includes the size of Image, the size of the emulated service and
> > the stack used by zboot. Finally we need a kexec_add_buffer() for this
> > range.
> >
> > -2. The emulated EFI services and some initial data such as the physical
> > address of dtb, the usable memory start address and size should be set
> > by kexec_purgatory_get_set_symbol()
> >
> > -3. Set up an identity mapping of the usable memory by zboot, prepare
> > stack and turn on MMU at the last point just before 'br efi_zboot_entry'
> > in relocate_kernel.S, which means relocate_kernel.S should support two
> > kinds of payload.
> >
> > -4. For efi_zboot_entry(), if jumping from kexec, limit its requirement
> > to only a few boot services: e.g. allocate_pages, allocate_pool. So the
> > emulated services can be deduced.
> 
> Hi Pingfan,
> 
> I'm not sure how hard it will be although Ard thinks it could be
> doable.  If it is not easy I suspect it is not worth the effort.
> 

Yes, it is a little hard comparing to the original patch. But I am also
trying in that direction.

> For your current series,  my suggestion is you can try to move the
> major code in the generic code path in kernel/kexec_file.c and keep
> the arch code minimum so that in the future other arches can avoid
> redundant code.
> 

OK. I will do it.

> Otherwise a fallback solution could be using the same key to sign both
> the zboot image and the internal kernel image like below:
> 1. sign the kernel with the same key twice (kernel image and zboot
> image) in distro kernel
> 2. introduce a kconfig in mainline to sign the kernel image with an
> ephemeral key same to kernel modules.  Distro can disable the config
> option. (in this way kexec can only load the same kernel, it is not
> useful if people want to load older/newer kernels)
> 3. patch kexec-tools to decompress the zboot image and load the kernel image
> 

Yes, this is also a doable way. I will try it if more votes for it.

Thanks,

	Pingfan
> >
> > > > kernel up to the point where it call ExitBootServices(), after which
> > > > kexec() would take over.
> > > >
> > >
> > > IIUC, after kexec switches to efi_zboot_entry(), it will not return,
> > > right?
> > >
> >
> > I have this assumption because letting the control path switch between
> > kernel and non-kernel code is not a good idea.
> >
> >
> > Thanks,
> >
> > Pingfan
> >
> > > > >  -3. in kernel space, during the file load
> > > > > of the zboot image. At that point, the kernel masters the whole memory
> > > > > information, and easily allocates a suitable memory for the decompressed
> > > > > kernel image. (I think this is similar to what grub does today).
> > > > >
> > > >
> > > > GRUB just calls LoadImage(), and the decompression code runs in the EFI context.
> > > >
> > >
> > > Ah, thanks for the correcting. I had made an wrong assumption of grub
> > > based on [1], from which, I thought that grub is the case "For
> > > compatibility with non-EFI loaders, the payload can be decompressed and
> > > executed by the loader as well, provided that the loader implements the
> > > decompression algorithm and that non-EFI boot is supported by the
> > > encapsulated image"
> > >
> > >
> > > [1]: https://www.phoronix.com/news/Linux-6.1-Generic-EFI-Zboot
> > >
> > >
> > > Eager to find a solution to kexec a zboot image. Hope it will come soon.
> > >
> > >
> > > Thanks,
> > >
> > >       Pingfan
> > > > > The core of this series is [5/6].  [3,6/6] handles the config option.
> > > > > The assumption of [3/6] is kexec_file_load is independent of zboot,
> > > > > especially it can load kernel images compressed with different
> > > > > compression method.  [6/6] is if EFI_ZBOOT, the corresponding
> > > > > decompression method should be included.
> > > > >
> > > > >
> > > > > Cc: Catalin Marinas <catalin.marinas@arm.com>
> > > > > Cc: Will Deacon <will@kernel.org>
> > > > > Cc: Andrew Morton <akpm@linux-foundation.org>
> > > > > Cc: Ard Biesheuvel <ardb@kernel.org>
> > > > > Cc: kexec@lists.infradead.org
> > > > > To: linux-arm-kernel@lists.infradead.org
> > > > > To: linux-kernel@vger.kernel.org
> > > > >
> > > > > Pingfan Liu (6):
> > > > >   arm64: kexec: Rename kexec_image.c to kexec_raw_image.c
> > > > >   lib/decompress: Introduce decompress_method_by_name()
> > > > >   arm64: Kconfig: Pick decompressing method for kexec file load
> > > > >   lib/decompress: Keep decompress routines based on selection
> > > > >   arm64: kexec: Introduce zboot image loader
> > > > >   init/Kconfig: Select decompressing method if compressing kernel
> > > > >
> > > > >  arch/arm64/Kconfig                            |  59 ++++++
> > > > >  arch/arm64/include/asm/kexec.h                |   4 +-
> > > > >  arch/arm64/kernel/Makefile                    |   2 +-
> > > > >  .../{kexec_image.c => kexec_raw_image.c}      |   2 +-
> > > > >  arch/arm64/kernel/kexec_zboot_image.c         | 186 ++++++++++++++++++
> > > > >  arch/arm64/kernel/machine_kexec.c             |   1 +
> > > > >  arch/arm64/kernel/machine_kexec_file.c        |   3 +-
> > > > >  include/linux/decompress/generic.h            |   2 +
> > > > >  include/linux/decompress/mm.h                 |   9 +-
> > > > >  include/linux/zboot.h                         |  26 +++
> > > > >  init/Kconfig                                  |   7 +
> > > > >  lib/Kconfig                                   |   3 +
> > > > >  lib/decompress.c                              |  17 +-
> > > > >  13 files changed, 314 insertions(+), 7 deletions(-)
> > > > >  rename arch/arm64/kernel/{kexec_image.c => kexec_raw_image.c} (98%)
> > > > >  create mode 100644 arch/arm64/kernel/kexec_zboot_image.c
> > > > >  create mode 100644 include/linux/zboot.h
> > > > >
> > > > > --
> > > > > 2.31.1
> > > > >
> >
> > _______________________________________________
> > kexec mailing list
> > kexec@lists.infradead.org
> > http://lists.infradead.org/mailman/listinfo/kexec
> >
> 

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel