From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754464AbdHYCEF (ORCPT ); Thu, 24 Aug 2017 22:04:05 -0400 Received: from mail-pg0-f45.google.com ([74.125.83.45]:33572 "EHLO mail-pg0-f45.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754265AbdHYCEE (ORCPT ); Thu, 24 Aug 2017 22:04:04 -0400 Date: Fri, 25 Aug 2017 11:03:51 +0900 From: AKASHI Takahiro To: Mark Rutland Cc: catalin.marinas@arm.com, will.deacon@arm.com, bauerman@linux.vnet.ibm.com, dhowells@redhat.com, vgoyal@redhat.com, herbert@gondor.apana.org.au, davem@davemloft.net, akpm@linux-foundation.org, mpe@ellerman.id.au, dyoung@redhat.com, bhe@redhat.com, arnd@arndb.de, ard.biesheuvel@linaro.org, kexec@lists.infradead.org, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org Subject: Re: [PATCH 14/14] arm64: kexec_file: add vmlinux format support Message-ID: <20170825020348.GA7308@akashi-kouhiroshi-no-MacBook-Air.local> Mail-Followup-To: AKASHI Takahiro , Mark Rutland , catalin.marinas@arm.com, will.deacon@arm.com, bauerman@linux.vnet.ibm.com, dhowells@redhat.com, vgoyal@redhat.com, herbert@gondor.apana.org.au, davem@davemloft.net, akpm@linux-foundation.org, mpe@ellerman.id.au, dyoung@redhat.com, bhe@redhat.com, arnd@arndb.de, ard.biesheuvel@linaro.org, kexec@lists.infradead.org, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org References: <20170824081811.19299-1-takahiro.akashi@linaro.org> <20170824081811.19299-15-takahiro.akashi@linaro.org> <20170824173049.GG29665@leverpostej> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170824173049.GG29665@leverpostej> User-Agent: Mutt/1.8.3 (2017-05-23) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Aug 24, 2017 at 06:30:50PM +0100, Mark Rutland wrote: > On Thu, Aug 24, 2017 at 05:18:11PM +0900, AKASHI Takahiro wrote: > > The first PT_LOAD segment, which is assumed to be "text" code, in vmlinux > > will be loaded at the offset of TEXT_OFFSET from the begining of system > > memory. The other PT_LOAD segments are placed relative to the first one. > > I really don't like assuming things about the vmlinux ELF file. If so, vmlinux is not an appropriate format for loading. > > Regarding kernel verification, since there is no standard way to contain > > a signature within elf binary, we follow PowerPC's (not yet upstreamed) > > approach, that is, appending a signature right after the kernel binary > > itself like module signing. > > I also *really* don't like this. It's a bizarre in-band mechanism, > without explcit information. It's not a nice ABI. > > If we can load an Image, why do we need to be able to load a vmlinux? Well, kexec-tools does. I don't know why Geoff wanted to support vmlinux. I'm just trying to support what kexec-tools does support. > [...] > > > diff --git a/arch/arm64/kernel/kexec_elf.c b/arch/arm64/kernel/kexec_elf.c > > new file mode 100644 > > index 000000000000..7bd3c1e1f65a > > --- /dev/null > > +++ b/arch/arm64/kernel/kexec_elf.c > > @@ -0,0 +1,216 @@ > > +/* > > + * Kexec vmlinux loader > > + > > + * Copyright (C) 2017 Linaro Limited > > + * Authors: AKASHI Takahiro > > + * > > + * This program is free software; you can redistribute it and/or modify > > + * it under the terms of the GNU General Public License version 2 as > > + * published by the Free Software Foundation. > > + */ > > + > > +#define pr_fmt(fmt) "kexec_file(elf): " fmt > > + > > +#include > > +#include > > +#include > > +#include > > +#include > > +#include > > +#include > > +#include > > +#include > > +#include > > +#include > > + > > +static int elf64_probe(const char *buf, unsigned long len) > > +{ > > + struct elfhdr ehdr; > > + > > + /* Check for magic and architecture */ > > + memcpy(&ehdr, buf, sizeof(ehdr)); > > + if (memcmp(ehdr.e_ident, ELFMAG, SELFMAG) || > > + (elf16_to_cpu(&ehdr, ehdr.e_machine) != EM_AARCH64)) > > + return -ENOEXEC; > > + > > + return 0; > > +} > > + > > +static int elf_exec_load(struct kimage *image, struct elfhdr *ehdr, > > + struct elf_info *elf_info, > > + unsigned long *kernel_load_addr) > > +{ > > + struct kexec_buf kbuf; > > + const struct elf_phdr *phdr; > > + const struct arm64_image_header *h; > > + unsigned long text_offset, rand_offset; > > + unsigned long page_offset, phys_offset; > > + int first_segment, i, ret = -ENOEXEC; > > + > > + 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; > > + > > + /* Load PT_LOAD segments. */ > > + for (i = 0, first_segment = 1; i < ehdr->e_phnum; i++) { > > + phdr = &elf_info->proghdrs[i]; > > + if (phdr->p_type != PT_LOAD) > > + continue; > > + > > + kbuf.buffer = (void *) elf_info->buffer + phdr->p_offset; > > + kbuf.bufsz = min(phdr->p_filesz, phdr->p_memsz); > > + kbuf.memsz = phdr->p_memsz; > > + kbuf.buf_align = phdr->p_align; > > + > > + if (first_segment) { > > + /* > > + * Identify TEXT_OFFSET: > > + * When CONFIG_ARM64_RANDOMIZE_TEXT_OFFSET=y the image > > + * header could be offset in the elf segment. The linker > > + * script sets ehdr->e_entry to the start of text. > > Please, let's not have to go delving into the vmlinux, knowing intimate > details about how it's put together. If we don't need to take care of RANDOMIZE_TEXT_OFFSET, the code would be much simpler and look similar to Image code. > > > + * > > + * NOTE: In v3.16 or older, h->text_offset is 0, > > + * so use the default, 0x80000 > > + */ > > + rand_offset = ehdr->e_entry - phdr->p_vaddr; > > + h = (struct arm64_image_header *) > > + (elf_info->buffer + phdr->p_offset + > > + rand_offset); > > + > > + if (!arm64_header_check_magic(h)) > > + goto out; > > + > > + if (h->image_size) > > + text_offset = le64_to_cpu(h->text_offset); > > + else > > + text_offset = 0x80000; > > Surely we can share the Image header parsing with the Image parser? > > The Image code had practically the exact same logic operating on the > header struct. Thanks, -Takahiro AKASHI > Thanks, > Mark.