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: NKevin Wolf <kwolf@redhat.com>
Reviewed-by: NJack Schwartz <jack.schwartz@oracle.com>

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: NKevin Wolf <kwolf@redhat.com>
Reviewed-by: NJack Schwartz <jack.schwartz@oracle.com>

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: NJack Schwartz <jack.schwartz@oracle.com>
Reviewed-by: NDaniel Kiper <daniel.kiper@oracle.com>
Signed-off-by: NKevin Wolf <kwolf@redhat.com>

Refer to field names when displaying fields in printf and debug statements.
Signed-off-by: NJack Schwartz <jack.schwartz@oracle.com>
Reviewed-by: NDaniel Kiper <daniel.kiper@oracle.com>
Signed-off-by: NKevin Wolf <kwolf@redhat.com>

Remove unused variables: mh_mode_type, mh_width, mh_height, mh_depth
Signed-off-by: NJack Schwartz <jack.schwartz@oracle.com>
Reviewed-by: NDaniel Kiper <daniel.kiper@oracle.com>
Reviewed-by: NPrasad J Pandit <pjp@fedoraproject.org>
Signed-off-by: NKevin Wolf <kwolf@redhat.com>

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: NDaniel Kiper <daniel.kiper@oracle.com>
Signed-off-by: NJack Schwartz <jack.schwartz@oracle.com>
Reviewed-by: NDaniel Kiper <daniel.kiper@oracle.com>
Reviewed-by: NPrasad J Pandit <pjp@fedoraproject.org>
Signed-off-by: NKevin Wolf <kwolf@redhat.com>

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: NEric Blake <eblake@redhat.com>
Reviewed-by: NPhilippe Mathieu-Daudé <f4bug@amsat.org>
Signed-off-by: NMarkus Armbruster <armbru@redhat.com>
Message-Id: <20180201111846.21846-20-armbru@redhat.com>
[Semantic conflict with commit bdd6a90a in block/nvme.c resolved]

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: NThomas Garnier <thgarnie@google.com>
Signed-off-by: NPrasad J Pandit <pjp@fedoraproject.org>
Message-Id: <20170907063256.7418-1-ppandit@redhat.com>
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>

I found these pattern via grepping the source tree. I don't have a
coccinelle script for it!
Signed-off-by: NMarc-André Lureau <marcandre.lureau@redhat.com>
Reviewed-by: NEduardo Habkost <ehabkost@redhat.com>
Reviewed-by: NRichard Henderson <rth@twiddle.net>

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: NVlad Lungu <vlad.lungu@windriver.com>
Message-Id: <1481805124-16242-1-git-send-email-vlad.lungu@windriver.com>
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>

Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>

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: NPeter Maydell <peter.maydell@linaro.org>
Signed-off-by: NPeter Crosthwaite <crosthwaite.peter@gmail.com>
Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>

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: NPeter Maydell <peter.maydell@linaro.org>
Message-id: 1453832250-766-11-git-send-email-peter.maydell@linaro.org

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: NEduardo Habkost <ehabkost@redhat.com>
Acked-by: NEduardo Habkost <ehabkost@redhat.com>
Reviewed-by: NRichard Henderson <rth@twiddle.net>
Acked-By: NRiku Voipio <riku.voipio@linaro.org>
Signed-off-by: NPeter Crosthwaite <crosthwaite.peter@gmail.com>
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>

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: NKevin Wolf <kwolf@redhat.com>
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>

The name is set to "qemu".
Signed-off-by: NDrew DeVault <sir@cmpwn.com>
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
Signed-off-by: NDrew DeVault <sircmpwn@gmail.com>
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>

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: NKevin Wolf <mail@kevin-wolf.de>
Reviewed-by: NAnthony Liguori <aliguori@us.ibm.com>
Message-id: 1372018066-21822-3-git-send-email-mail@kevin-wolf.de
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

Currently some places use pointer-to-void even though they mean
pointer-to-FWCfgState. Clean them up.
Signed-off-by: NLaszlo Ersek <lersek@redhat.com>
Reviewed-by: NAnthony Liguori <aliguori@us.ibm.com>
Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>

Many headers are used only in a single directory.  These can be
kept in hw/.
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>

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: NPaolo Bonzini <pbonzini@redhat.com>

Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>

Done with this script:

cd hw
for i in `find . -name '*.h' | sed 's/^..//'`; do
  echo '\,^#.*include.*["<]'$i'[">], s,'$i',hw/&,'
done | sed -i -f - `find . -type f`

This is so that paths remain valid as files are moved.

Instead, files in hw/dataplane are referenced with the relative path.
We know they are not going to move to include/, and they are the only
include files that are in subdirectories _and_ move.
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>

Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>

target_phys_addr_t is unwieldly, violates the C standard (_t suffixes are
reserved) and its purpose doesn't match the name (most target_phys_addr_t
addresses are not target specific).  Replace it with a finger-friendly,
standards conformant hwaddr.

Outstanding patchsets can be fixed up with the command

  git rebase -i --exec 'find -name "*.[ch]"
                        | xargs s/target_phys_addr_t/hwaddr/g' origin
Signed-off-by: NAvi Kivity <avi@redhat.com>
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

The previous multiboot load code did not treat the case where
load_end_addr was 0 specially.  The multiboot specification says the
following:
 * load_end_addr
   Contains the physical address of the end of the data segment.
   (load_end_addr - load_addr) specifies how much data to load. This
   implies that the text and data segments must be consecutive in the
   OS image; this is true for existing a.out executable formats. If
   this field is zero, the boot loader assumes that the text and data
   segments occupy the whole OS image file.
Signed-off-by: NScott Moser <smoser@ubuntu.com>
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

qemu_malloc/qemu_free no longer exist after this commit.
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

Multiboot images can specify a bss segment. The boot loader must clear
the memory of the bss and ensure that no modules or structures are
allocated inside it. Several fields are provided in the Multiboot
header that were previously not used properly. The header is now used
to determine how much data should be read from the image and how much
memory should be reserved to the bss segment.
Signed-off-by: NGöran Weinholt <goran@weinholt.se>
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

Support commas in the parameter list of multiboot modules as well as for the
kernel command line, by using double commas (via get_opt_value()).
Signed-off-by: NAdam Lackorzynski <adam@os.inf.tu-dresden.de>
Reviewed-by: NKevin Wolf <kwolf@redhat.com>
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

The multiboot info struct's 'boot_device' field has 'part1' set to 0x01, which
maps to the second primary partition. To specify the first primary partition,
'part1' should be set to 0x00, since partition numbers start from zero
according to the multiboot spec.
Signed-off-by: NArun Thomas <arun.thomas@gmail.com>
Reviewed-by: NStefan Hajnoczi <stefanha@linux.vnet.ibm.com>
Signed-off-by: NAurelien Jarno <aurelien@aurel32.net>

Quote filename in error message to spot possible whitespace character in
the filename and make error message more meaningful.
Signed-off-by: NAdam Lackorzynski <adam@os.inf.tu-dresden.de>
Acked-by: NAlexander Graf <agraf@suse.de>
Signed-off-by: NStefan Hajnoczi <stefanha@linux.vnet.ibm.com>

The upper memory size field should exclude the first MB of RAM.
Signed-off-by: NKevin Wolf <mail@kevin-wolf.de>
Signed-off-by: NAurelien Jarno <aurelien@aurel32.net>

Extend -option-rom command to have additional parameter ,bootindex=.
Signed-off-by: NGleb Natapov <gleb@redhat.com>
Signed-off-by: NBlue Swirl <blauwirbel@gmail.com>

A via -kernel supplied x86_64 ELF image is being started in 32bit mode.
Detect and exit if a 64bit image has been supplied.
Signed-off-by: NAdam Lackorzynski <adam@os.inf.tu-dresden.de>
Acked-by: NAlexander Graf <agraf@suse.de>
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

Do not store return of get_image_size() in a uint32_t as it makes it
impossible to detect error returns from get_image_size.
Signed-off-by: NJes Sorensen <Jes.Sorensen@redhat.com>
Signed-off-by: NBlue Swirl <blauwirbel@gmail.com>

This patch fixes the following compilation errors in multiboot.c
when DEBUG_MULTIBOOT is defined.
Use TARGET_FMT_plx instead of %x for target_phys_addr_t.

  CC    i386-softmmu/multiboot.o
cc1: warnings being treated as errors
qemu/hw/multiboot.c: In function 'mb_add_mod':
qemu/hw/multiboot.c:121: error: format '%08x' expects type 'unsigned int', but argument 4 has type 'target_phys_addr_t'
qemu/hw/multiboot.c:121: error: format '%08x' expects type 'unsigned int', but argument 5 has type 'target_phys_addr_t'
qemu/hw/multiboot.c: In function 'load_multiboot':
qemu/hw/multiboot.c:279: error: format '%#x' expects type 'unsigned int', but argument 5 has type 'target_phys_addr_t'
qemu/hw/multiboot.c:307: error: format '%x' expects type 'unsigned int', but argument 3 has type 'target_phys_addr_t'
qemu/hw/multiboot.c:308: error: format '%x' expects type 'unsigned int', but argument 3 has type 'target_phys_addr_t'
make[1]: *** [multiboot.o] Error 1
Signed-off-by: NIsaku Yamahata <yamahata@valinux.co.jp>
Signed-off-by: NBlue Swirl <blauwirbel@gmail.com>

A few machines need to translate the ELF header addresses into physical
addresses. Currently the only possibility is to add a value to the
addresses.

This patch replaces the addend argument by and a translation function
and an opaque passed to the function. A NULL function does not translate
the address.

The patch also convert all machines that have an addend, simplify the
PowerPC kernel loading and fix the MIPS kernel loading using this new
feature. Other machines may benefit from this feature.
Signed-off-by: NAurelien Jarno <aurelien@aurel32.net>

Move multiboot loading code into separate files as suggested by Alex Graf.
Signed-off-by: NAdam Lackorzynski <adam@os.inf.tu-dresden.de>
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>