From: linux@arm.linux.org.uk (Russell King - ARM Linux) To: linux-arm-kernel@lists.infradead.org Subject: [PATCH v2 6/8] arm: allow passing an ELF64 header to elf_check_arch() Date: Mon, 10 May 2010 13:21:56 +0100 [thread overview] Message-ID: <20100510122156.GA7796@n2100.arm.linux.org.uk> (raw) In-Reply-To: <20100510120920.GD11783@esdhcp04058.research.nokia.com> On Mon, May 10, 2010 at 03:09:20PM +0300, Mika Westerberg wrote: > I believe that when passing ELF64 header, it fails in following checks: > > /* Make sure it's an ARM executable */ > if (x->e_ident[EI_CLASS] != ELF_CLASS) > return 0; > if (x->e_machine != EM_ARM) > return 0; > > ELF_CLASS is defined in arch/arm/include/asm/elf.h: > > #define ELF_CLASS ELFCLASS32 > > So if class is different than ELFCLASS32 it returns 0 and never even try to > access other fields, right? Yes. > > Now, here's the question: why does this crashkernel stuff want to > > parse a 64-bit ELF header on a 32-bit only platform where the crashing > > kernel will never generate a 64-bit ELF core file? > > I really don't know but fs/proc/vmcore.c is coded in such way that it supports > both types of ELF headers. It however, passes the header to elf_check_arch() > which in our case should fail if it is something else than ELF32 header. There's other arches which want elf_check_arch to be a function call, so I think my question needs to be looked at more closely - and possibly the code changed such that we don't end up with this situation. Maybe a cleaner solution would be for vmcore.c to split its calls to elf_check_arch() - to be elf32_check_arch() and elf64_check_arch() ? Platforms where it's just a macro can define both to be elf_check_arch() but those where only one flavour is supported should define the unsupported flavour to zero - which incidentally would allow the compiler to optimize away the unnecessary parts of parse_crash_elf*_headers().
WARNING: multiple messages have this Message-ID (diff)
From: Russell King - ARM Linux <linux@arm.linux.org.uk> To: Mika Westerberg <ext-mika.1.westerberg@nokia.com> Cc: "kexec@lists.infradead.org" <kexec@lists.infradead.org>, "linux-arm-kernel@lists.infradead.org" <linux-arm-kernel@lists.infradead.org> Subject: Re: [PATCH v2 6/8] arm: allow passing an ELF64 header to elf_check_arch() Date: Mon, 10 May 2010 13:21:56 +0100 [thread overview] Message-ID: <20100510122156.GA7796@n2100.arm.linux.org.uk> (raw) In-Reply-To: <20100510120920.GD11783@esdhcp04058.research.nokia.com> On Mon, May 10, 2010 at 03:09:20PM +0300, Mika Westerberg wrote: > I believe that when passing ELF64 header, it fails in following checks: > > /* Make sure it's an ARM executable */ > if (x->e_ident[EI_CLASS] != ELF_CLASS) > return 0; > if (x->e_machine != EM_ARM) > return 0; > > ELF_CLASS is defined in arch/arm/include/asm/elf.h: > > #define ELF_CLASS ELFCLASS32 > > So if class is different than ELFCLASS32 it returns 0 and never even try to > access other fields, right? Yes. > > Now, here's the question: why does this crashkernel stuff want to > > parse a 64-bit ELF header on a 32-bit only platform where the crashing > > kernel will never generate a 64-bit ELF core file? > > I really don't know but fs/proc/vmcore.c is coded in such way that it supports > both types of ELF headers. It however, passes the header to elf_check_arch() > which in our case should fail if it is something else than ELF32 header. There's other arches which want elf_check_arch to be a function call, so I think my question needs to be looked at more closely - and possibly the code changed such that we don't end up with this situation. Maybe a cleaner solution would be for vmcore.c to split its calls to elf_check_arch() - to be elf32_check_arch() and elf64_check_arch() ? Platforms where it's just a macro can define both to be elf_check_arch() but those where only one flavour is supported should define the unsupported flavour to zero - which incidentally would allow the compiler to optimize away the unnecessary parts of parse_crash_elf*_headers(). _______________________________________________ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
next prev parent reply other threads:[~2010-05-10 12:21 UTC|newest] Thread overview: 54+ messages / expand[flat|nested] mbox.gz Atom feed top 2010-05-05 6:54 [PATCH v2 0/8] Initial implementation of kdump for ARM Mika Westerberg 2010-05-05 6:54 ` Mika Westerberg 2010-05-05 6:54 ` [PATCH v2 1/8] arm: kdump: reserve memory for crashkernel Mika Westerberg 2010-05-05 6:54 ` Mika Westerberg 2010-05-05 6:54 ` [PATCH v2 2/8] arm: kdump: implement crash_setup_regs() Mika Westerberg 2010-05-05 6:54 ` Mika Westerberg 2010-05-05 6:54 ` [PATCH v2 3/8] arm: kdump: implement machine_crash_shutdown() Mika Westerberg 2010-05-05 6:54 ` Mika Westerberg 2010-05-05 6:54 ` [PATCH v2 4/8] arm: kdump: skip indirection page when crashing Mika Westerberg 2010-05-05 6:54 ` Mika Westerberg 2010-05-05 6:54 ` [PATCH v2 5/8] arm: kdump: implement copy_oldmem_page() Mika Westerberg 2010-05-05 6:54 ` Mika Westerberg 2010-05-05 6:54 ` [PATCH v2 6/8] arm: allow passing an ELF64 header to elf_check_arch() Mika Westerberg 2010-05-05 6:54 ` Mika Westerberg 2010-05-10 11:20 ` Russell King - ARM Linux 2010-05-10 11:20 ` Russell King - ARM Linux 2010-05-10 12:09 ` Mika Westerberg 2010-05-10 12:09 ` Mika Westerberg 2010-05-10 12:21 ` Russell King - ARM Linux [this message] 2010-05-10 12:21 ` Russell King - ARM Linux 2010-05-11 7:17 ` Mika Westerberg 2010-05-11 7:17 ` Mika Westerberg 2010-07-16 8:14 ` Mika Westerberg 2010-07-16 8:14 ` Mika Westerberg 2010-08-25 2:40 ` Lei Wen 2010-08-25 2:40 ` Lei Wen 2010-08-25 12:29 ` Mika Westerberg 2010-08-25 12:29 ` Mika Westerberg 2010-05-05 6:54 ` [PATCH v2 7/8] arm: kdump: add support for elfcorehdr= parameter Mika Westerberg 2010-05-05 6:54 ` Mika Westerberg 2010-05-05 6:54 ` [PATCH v2 8/8] arm: kdump: add CONFIG_CRASH_DUMP Kconfig option Mika Westerberg 2010-05-05 6:54 ` Mika Westerberg 2010-05-25 8:19 ` [PATCH v2 0/8] Initial implementation of kdump for ARM Mika Westerberg 2010-05-25 8:19 ` Mika Westerberg 2010-06-11 6:36 ` Mika Westerberg 2010-07-02 12:48 ` Per Fransson 2010-07-05 8:28 ` Mika Westerberg 2010-07-05 10:01 ` Per Fransson 2010-07-05 10:18 ` Russell King - ARM Linux 2010-07-05 10:34 ` Per Fransson 2010-07-05 11:31 ` Mika Westerberg 2010-07-05 12:04 ` Per Fransson 2010-07-05 13:55 ` Russell King - ARM Linux 2010-07-05 14:05 ` Per Fransson 2010-07-05 14:19 ` Russell King - ARM Linux 2010-07-05 15:37 ` Per Fransson 2010-07-05 16:08 ` Nicolas Pitre 2010-07-05 18:14 ` Russell King - ARM Linux 2010-07-06 8:30 ` Per Fransson 2010-07-07 7:29 ` Mika Westerberg 2010-07-08 8:52 ` Per Fransson 2010-07-12 8:20 ` Mika Westerberg 2010-07-09 3:38 ` Simon Horman 2010-07-09 8:19 ` Per Fransson
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=20100510122156.GA7796@n2100.arm.linux.org.uk \ --to=linux@arm.linux.org.uk \ --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: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.