summary refs log tree commit diff stats
path: root/hw/i386/multiboot.c (follow)
Commit message (Collapse)AuthorAgeFilesLines
* opts: don't silently truncate long option valuesDaniel P. Berrangé2018-05-091-12/+21
| | | | | | | | | | | | | | | | | | | | | | | | | | | The existing QemuOpts parsing code uses a fixed size 1024 byte buffer for storing the option values. If a value exceeded this size it was silently truncated and no error reported to the user. Long option values is not a common scenario, but it is conceivable that they will happen. eg if the user has a very deeply nested filesystem it would be possible to come up with a disk path that was > 1024 bytes. Most of the time if such data was silently truncated, the user would get an error about opening a non-existant disk. If they're unlucky though, QEMU might use a completely different disk image from another VM, which could be considered a security issue. Another example program was in using the -smbios command line arg with very large data blobs. In this case the silent truncation will be providing semantically incorrect data to the guest OS for SMBIOS tables. If the operating system didn't limit the user's argv when spawning QEMU, the code should honour whatever length arguments were given without imposing its own length restrictions. This patch thus changes the code to use a heap allocated buffer for storing the values during parsing, lifting the arbitrary length restriction. Signed-off-by: Daniel P. Berrangé <berrange@redhat.com> Message-Id: <20180416111743.8473-4-berrange@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
* multiboot: Check validity of mh_header_addrKevin Wolf2018-03-211-0/+4
| | | | | | | | | I couldn't find a case where this prevents something bad from happening that isn't already caught by other checks, but let's err on the safe side and check that mh_header_addr is as expected. Signed-off-by: Kevin Wolf <kwolf@redhat.com> Reviewed-by: Jack Schwartz <jack.schwartz@oracle.com>
* multiboot: Reject kernels exceeding the address spaceKevin Wolf2018-03-211-0/+4
| | | | | | | | | | | | | | | | The code path where mh_load_end_addr is non-zero in the Multiboot header checks that mh_load_end_addr >= mh_load_addr and so mb_load_size is checked. However, mb_load_size is not checked when calculated from the file size, when mh_load_end_addr is 0. If the kernel binary size is larger than can fit in the address space after load_addr, we ended up with a kernel_size that is smaller than load_size, which means that we read the file into a too small buffer. Add a check to reject kernel files with such Multiboot headers. Signed-off-by: Kevin Wolf <kwolf@redhat.com> Reviewed-by: Jack Schwartz <jack.schwartz@oracle.com>
* multiboot: fprintf(stderr...) -> error_report()Jack Schwartz2018-03-071-26/+29
| | | | | | | | | | | Change all fprintf(stderr...) calls in hw/i386/multiboot.c to call error_report() instead, including the mb_debug macro. Remove the "\n" from strings passed to all modified calls, since error_report() appends one. Signed-off-by: Jack Schwartz <jack.schwartz@oracle.com> Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
* multiboot: Use header names when displaying fieldsJack Schwartz2018-03-071-8/+8
| | | | | | | | Refer to field names when displaying fields in printf and debug statements. Signed-off-by: Jack Schwartz <jack.schwartz@oracle.com> Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
* multiboot: Remove unused variables from multiboot.cJack Schwartz2018-03-071-6/+0
| | | | | | | | | Remove unused variables: mh_mode_type, mh_width, mh_height, mh_depth Signed-off-by: Jack Schwartz <jack.schwartz@oracle.com> Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com> Reviewed-by: Prasad J Pandit <pjp@fedoraproject.org> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
* multiboot: bss_end_addr can be zeroJack Schwartz2018-03-071-8/+10
| | | | | | | | | | | | | The multiboot spec (https://www.gnu.org/software/grub/manual/multiboot/), section 3.1.3, allows for bss_end_addr to be zero. A zero bss_end_addr signifies there is no .bss section. Suggested-by: Daniel Kiper <daniel.kiper@oracle.com> Signed-off-by: Jack Schwartz <jack.schwartz@oracle.com> Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com> Reviewed-by: Prasad J Pandit <pjp@fedoraproject.org> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
* Move include qemu/option.h from qemu-common.h to actual usersMarkus Armbruster2018-02-091-1/+1
| | | | | | | | | | | | | | | | | | qemu-common.h includes qemu/option.h, but most places that include the former don't actually need the latter. Drop the include, and add it to the places that actually need it. While there, drop superfluous includes of both headers, and separate #include from file comment with a blank line. This cleanup makes the number of objects depending on qemu/option.h drop from 4545 (out of 4743) to 284 in my "build everything" tree. Reviewed-by: Eric Blake <eblake@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Signed-off-by: Markus Armbruster <armbru@redhat.com> Message-Id: <20180201111846.21846-20-armbru@redhat.com> [Semantic conflict with commit bdd6a90a9e in block/nvme.c resolved]
* multiboot: validate multiboot header address valuesPrasad J Pandit2017-09-191-0/+19
| | | | | | | | | | | | | | | While loading kernel via multiboot-v1 image, (flags & 0x00010000) indicates that multiboot header contains valid addresses to load the kernel image. These addresses are used to compute kernel size and kernel text offset in the OS image. Validate these address values to avoid an OOB access issue. This is CVE-2017-14167. Reported-by: Thomas Garnier <thgarnie@google.com> Signed-off-by: Prasad J Pandit <pjp@fedoraproject.org> Message-Id: <20170907063256.7418-1-ppandit@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
* i386: replace g_malloc()+memcpy() with g_memdup()Marc-André Lureau2017-08-311-2/+1
| | | | | | | | | I found these pattern via grepping the source tree. I don't have a coccinelle script for it! Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com> Reviewed-by: Eduardo Habkost <ehabkost@redhat.com> Reviewed-by: Richard Henderson <rth@twiddle.net>
* multiboot: copy the cmdline verbatim, unescape module stringsVlad Lungu2016-12-221-10/+10
| | | | | | | | | | | | get_opt_value() truncates the value at the first comma Use memcpy() instead so that -append works correctly in the presence of commas. For -initrd to work right, instead, unescape the module filename and parameters with get_opt_value() before calling mb_add_cmdline(). Signed-off-by: Vlad Lungu <vlad.lungu@windriver.com> Message-Id: <1481805124-16242-1-git-send-email-vlad.lungu@windriver.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
* hw: explicitly include qemu-common.h and cpu.hPaolo Bonzini2016-03-221-0/+2
| | | | Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
* loader: Add data swap option to load-elfPeter Crosthwaite2016-03-041-1/+2
| | | | | | | | | | | | | | | | | | | | | | | Some CPUs are of an opposite data-endianness to other components in the system. Sometimes elfs have the data sections layed out with this CPU data-endianness accounting for when loaded via the CPU, so byte swaps (relative to other system components) will occur. The leading example, is ARM's BE32 mode, which is is basically LE with address manipulation on half-word and byte accesses to access the hw/byte reversed address. This means that word data is invariant across LE and BE32. This also means that instructions are still LE. The expectation is that the elf will be loaded via the CPU in this endianness scheme, which means the data in the elf is reversed at compile time. As QEMU loads via the system memory directly, rather than the CPU, we need a mechanism to reverse elf data endianness to implement this possibility. Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Peter Crosthwaite <crosthwaite.peter@gmail.com> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
* x86: Clean up includesPeter Maydell2016-01-291-0/+1
| | | | | | | | | | Clean up includes so that osdep.h is included first and headers which it implies are not included manually. This commit was created with scripts/clean-includes. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Message-id: 1453832250-766-11-git-send-email-peter.maydell@linaro.org
* i386: Rename ELF_MACHINE to be x86 specificPeter Crosthwaite2015-09-251-1/+1
| | | | | | | | | | | | | | | | | | | | | Rename ELF_MACHINE to be I386 specific. This is used as-is by the multiboot loader. Linux-user previously used this definition but will not anymore, falling back to the default bahaviour of using ELF_ARCH as ELF_MACHINE. This removes another architecture specific definition from the global namespace. Cc: Paolo Bonzini <pbonzini@redhat.com> Cc: Richard Henderson <rth@twiddle.net> Cc: Eduardo Habkost <ehabkost@redhat.com> Reviewed-by: Eduardo Habkost <ehabkost@redhat.com> Acked-by: Eduardo Habkost <ehabkost@redhat.com> Reviewed-by: Richard Henderson <rth@twiddle.net> Acked-By: Riku Voipio <riku.voipio@linaro.org> Signed-off-by: Peter Crosthwaite <crosthwaite.peter@gmail.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
* multiboot: Fix offset of bootloader nameKevin Wolf2015-01-261-7/+9
| | | | | | | | | | | | This fixes a bug introduced in commit 5eba5a66 ('Add bootloader name to multiboot implementation'). The calculation of the bootloader name offset didn't consider space occupied by module command lines, so some unlucky module got its command line partially overwritten with a "qemu" string. Signed-off-by: Kevin Wolf <kwolf@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
* Add bootloader name to multiboot implementationDrew DeVault2014-12-151-5/+27
| | | | | | | | | The name is set to "qemu". Signed-off-by: Drew DeVault <sir@cmpwn.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Signed-off-by: Drew DeVault <sircmpwn@gmail.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
* multiboot: Calculate upper_mem in the ROMKevin Wolf2013-06-281-2/+0
| | | | | | | | | | | | | | | | | | The upper_mem field of the Multiboot information struct doesn't really contain the RAM size - 1 MB like we used to calculate it, but only the memory from 1 MB up to the first (upper) memory hole. In order to correctly retrieve this information, the multiboot ROM now looks at the mmap it creates anyway and tries to find the size of contiguous usable memory from 1 MB. Drop the multiboot.c definition of lower_mem and upper_mem because both are queried at runtime now. Signed-off-by: Kevin Wolf <mail@kevin-wolf.de> Reviewed-by: Anthony Liguori <aliguori@us.ibm.com> Message-id: 1372018066-21822-3-git-send-email-mail@kevin-wolf.de Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
* refer to FWCfgState explicitlyLaszlo Ersek2013-06-021-1/+1
| | | | | | | | | Currently some places use pointer-to-void even though they mean pointer-to-FWCfgState. Clean them up. Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Anthony Liguori <aliguori@us.ibm.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
* hw: move private headers to hw/ subdirectories.Paolo Bonzini2013-04-081-1/+1
| | | | | | | Many headers are used only in a single directory. These can be kept in hw/. Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
* hw: move headers to include/Paolo Bonzini2013-04-081-1/+1
| | | | | | | | | Many of these should be cleaned up with proper qdev-/QOM-ification. Right now there are many catch-all headers in include/hw/ARCH depending on cpu.h, and this makes it necessary to compile these files per-target. However, fixing this does not belong in these patches. Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
* hw: move boards and other isolated files to hw/ARCHPaolo Bonzini2013-03-011-0/+349
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>