From: mark.rutland@arm.com (Mark Rutland)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 13/14] arm64: kexec_file: add Image format support
Date: Thu, 24 Aug 2017 18:23:37 +0100 [thread overview]
Message-ID: <20170824172337.GF29665@leverpostej> (raw)
In-Reply-To: <20170824081811.19299-14-takahiro.akashi@linaro.org>
On Thu, Aug 24, 2017 at 05:18:10PM +0900, AKASHI Takahiro wrote:
> The "Image" binary will be loaded at the offset of TEXT_OFFSET from
> the start of system memory. TEXT_OFFSET is basically determined from
> the header of the image.
What's the policy for the binary types kexec_file_load() will load, and
how are these identified? AFAICT, there are no flags, so it looks like
we're just checking the magic and hoping.
> Regarding kernel verification, it will be done through
> verify_pefile_signature() as arm64's "Image" binary can be seen as
> in PE format. This approach is consistent with x86 implementation.
This will not work for kernels built without CONFIG_EFI, where we don't
have a PE header.
What happens in that case?
[...]
> +/**
> + * arm64_header_check_msb - Helper to check the arm64 image header.
> + *
> + * Returns non-zero if the image was built as big endian.
> + */
> +
> +static inline int arm64_header_check_msb(const struct arm64_image_header *h)
> +{
> + if (!h)
> + return 0;
> +
> + return !!(h->flags[7] & arm64_image_flag_7_be);
> +}
What are we going to use this for?
In kernel, we use the term "BE" rather than "MSB", and it's unfortunate
to have code with varying naming conventions.
[...]
> +static void *image_load(struct kimage *image, char *kernel,
> + unsigned long kernel_len, char *initrd,
> + unsigned long initrd_len, char *cmdline,
> + unsigned long cmdline_len)
> +{
> + struct kexec_buf kbuf;
> + struct arm64_image_header *h = (struct arm64_image_header *)kernel;
> + unsigned long text_offset, kernel_load_addr;
> + int ret;
> +
> + /* Create elf core header segment */
> + ret = load_crashdump_segments(image);
> + if (ret)
> + goto out;
> +
> + /* Load the kernel */
> + kbuf.image = image;
> + if (image->type == KEXEC_TYPE_CRASH) {
> + kbuf.buf_min = crashk_res.start;
> + kbuf.buf_max = crashk_res.end + 1;
> + } else {
> + kbuf.buf_min = 0;
> + kbuf.buf_max = ULONG_MAX;
> + }
> + kbuf.top_down = 0;
> +
> + kbuf.buffer = kernel;
> + kbuf.bufsz = kernel_len;
> + if (h->image_size) {
> + kbuf.memsz = le64_to_cpu(h->image_size);
> + text_offset = le64_to_cpu(h->text_offset);
> + } else {
> + /* v3.16 or older */
> + kbuf.memsz = kbuf.bufsz; /* NOTE: not including BSS */
Why bother supporting < 3.16 kernels?
They predate regulate kexec, we know we don't have enough information to
boot such kernels reliably, and arguably attempting to load one would
indicate some kind of rollback attack.
Thanks,
Mark.
next prev parent reply other threads:[~2017-08-24 17:23 UTC|newest]
Thread overview: 49+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-08-24 8:17 [PATCH 00/14] arm64: kexec: add kexec_file_load support AKASHI Takahiro
2017-08-24 8:17 ` [PATCH 01/14] MODSIGN: Export module signature definitions AKASHI Takahiro
2017-08-24 8:17 ` [PATCH 02/14] include: pe.h: remove message[] from mz header definition AKASHI Takahiro
2017-08-24 9:04 ` Ard Biesheuvel
2017-08-24 8:18 ` [PATCH 03/14] resource: add walk_system_ram_res_rev() AKASHI Takahiro
2017-08-24 9:06 ` Ard Biesheuvel
2017-08-25 0:50 ` AKASHI Takahiro
2017-08-31 2:34 ` Pratyush Anand
2017-09-08 2:33 ` AKASHI Takahiro
2017-08-24 8:18 ` [PATCH 04/14] kexec_file: factor out vmlinux (elf) parser from powerpc AKASHI Takahiro
2017-08-24 8:18 ` [PATCH 05/14] kexec_file: factor out crashdump elf header function from x86 AKASHI Takahiro
2017-08-25 5:47 ` Dave Young
2017-09-08 2:31 ` AKASHI Takahiro
2017-08-24 8:18 ` [PATCH 06/14] kexec_file: add kexec_add_segment() AKASHI Takahiro
2017-08-24 8:18 ` [PATCH 07/14] asm-generic: add kexec_file_load system call to unistd.h AKASHI Takahiro
2017-08-24 10:53 ` Arnd Bergmann
2017-08-24 8:18 ` [PATCH 08/14] arm64: kexec_file: create purgatory AKASHI Takahiro
2017-08-24 9:10 ` Ard Biesheuvel
2017-08-25 1:10 ` AKASHI Takahiro
2017-08-24 16:56 ` Mark Rutland
2017-08-25 1:00 ` AKASHI Takahiro
2017-08-25 10:22 ` Mark Rutland
2017-08-25 16:16 ` Thiago Jung Bauermann
2017-09-08 2:46 ` AKASHI Takahiro
2017-08-24 8:18 ` [PATCH 09/14] arm64: kexec_file: add sha256 digest check in purgatory AKASHI Takahiro
2017-08-24 9:13 ` Ard Biesheuvel
2017-08-25 1:25 ` AKASHI Takahiro
2017-08-24 17:04 ` Mark Rutland
2017-08-25 1:21 ` AKASHI Takahiro
2017-08-25 10:41 ` Mark Rutland
2017-09-08 2:50 ` AKASHI Takahiro
2017-09-08 15:59 ` Thiago Jung Bauermann
2017-08-24 8:18 ` [PATCH 10/14] arm64: kexec_file: load initrd, device-tree and purgatory segments AKASHI Takahiro
2017-08-24 17:11 ` Mark Rutland
2017-08-25 1:34 ` AKASHI Takahiro
2017-08-24 8:18 ` [PATCH 11/14] arm64: kexec_file: set up for crash dump adding elf core header AKASHI Takahiro
2017-08-24 8:18 ` [PATCH 12/14] arm64: enable KEXEC_FILE config AKASHI Takahiro
2017-08-24 8:18 ` [PATCH 13/14] arm64: kexec_file: add Image format support AKASHI Takahiro
2017-08-24 17:23 ` Mark Rutland [this message]
2017-08-25 1:49 ` AKASHI Takahiro
2017-08-24 8:18 ` [PATCH 14/14] arm64: kexec_file: add vmlinux " AKASHI Takahiro
2017-08-24 17:30 ` Mark Rutland
2017-08-25 2:03 ` AKASHI Takahiro
2017-08-25 6:13 ` Dave Young
2017-09-08 2:54 ` AKASHI Takahiro
2017-08-29 10:01 ` Mark Rutland
2017-08-29 16:15 ` Thiago Jung Bauermann
2017-08-30 8:40 ` Michael Ellerman
2017-09-08 3:07 ` AKASHI Takahiro
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20170824172337.GF29665@leverpostej \
--to=mark.rutland@arm.com \
--cc=linux-arm-kernel@lists.infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).