From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:57818) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W0OOm-0005Vd-15 for qemu-devel@nongnu.org; Mon, 06 Jan 2014 23:36:24 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1W0OOd-0005Hs-ON for qemu-devel@nongnu.org; Mon, 06 Jan 2014 23:36:15 -0500 Received: from e23smtp05.au.ibm.com ([202.81.31.147]:55905) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W0OOd-0005Hj-1N for qemu-devel@nongnu.org; Mon, 06 Jan 2014 23:36:07 -0500 Received: from /spool/local by e23smtp05.au.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Tue, 7 Jan 2014 14:36:02 +1000 From: Alexey Kardashevskiy Date: Tue, 7 Jan 2014 15:35:53 +1100 Message-Id: <1389069353-13467-1-git-send-email-aik@ozlabs.ru> Subject: [Qemu-devel] [RFC PATCH] elf loader: exit if incompatible architecture is detected List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org Cc: Alexey Kardashevskiy , Paolo Bonzini , qemu-ppc@nongnu.org, Alexander Graf , Anthony Liguori If we know for sure that the image in "-kernel" is an ELF and we know its architecture and it is not supported by the current QEMU, there is no point to continue trying booting this image so let's exit once we deteced this fact. Signed-off-by: Alexey Kardashevskiy --- One of our users tried an X86 image with qemu-system-ppc64. Instead of printing some reasonable message (which is possible in this case as the image is ELF), QEMU (spapr.c) simply copied the image in RAM as a raw image and SLOF failed to boot from it. The patch fixes the issue but there are still questions. 1. Do we need more sophisticated error checking here? Return -2 instead of exit(1) and do exit(1) few levels up? 2. The patch does not handle x86's vmlinuz case - these images are not ELFs but "Linux kernel x86 boot executable bzImage" and QEMU does not parse them. As a result, SLOF crashes with the registers dump. Do we really care to handle this? --- include/hw/elf_ops.h | 13 +++++++++---- 1 file changed, 9 insertions(+), 4 deletions(-) diff --git a/include/hw/elf_ops.h b/include/hw/elf_ops.h index acc701e..6bcc61f 100644 --- a/include/hw/elf_ops.h +++ b/include/hw/elf_ops.h @@ -212,21 +212,21 @@ static int glue(load_elf, SZ)(const char *name, int fd, case EM_PPC64: if (EM_PPC64 != ehdr.e_machine) if (EM_PPC != ehdr.e_machine) - goto fail; + goto arch_fail; break; case EM_X86_64: if (EM_X86_64 != ehdr.e_machine) if (EM_386 != ehdr.e_machine) - goto fail; + goto arch_fail; break; case EM_MICROBLAZE: if (EM_MICROBLAZE != ehdr.e_machine) if (EM_MICROBLAZE_OLD != ehdr.e_machine) - goto fail; + goto arch_fail; break; default: if (elf_machine != ehdr.e_machine) - goto fail; + goto arch_fail; } if (pentry) @@ -306,4 +306,9 @@ static int glue(load_elf, SZ)(const char *name, int fd, g_free(data); g_free(phdr); return -1; + +arch_fail: + fprintf(stderr, "qemu: could not load arch-incompatible kernel '%s'\n", + name); + exit(1); } -- 1.8.4.rc4