qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Kevin Wolf <kwolf@redhat.com>
To: Markus Armbruster <armbru@redhat.com>
Cc: qemu-devel@nongnu.org, agraf@suse.de
Subject: Re: [Qemu-devel] [FOR 0.12][PATCH] Fix loading of ELF multiboot kernels
Date: Wed, 16 Dec 2009 11:11:34 +0100	[thread overview]
Message-ID: <4B28B256.2020605@redhat.com> (raw)
In-Reply-To: <m3tyvr9rhv.fsf@crossbow.pond.sub.org>

Am 16.12.2009 10:51, schrieb Markus Armbruster:
> Kevin Wolf <kwolf@redhat.com> writes:
> 
>> The multiboot implementation assumed that there is only one program header
>> (which contains the entry point) and that the entry point is at the start of
>> the code. This doesn't hold true generally and caused too little data to be
>> loaded.
> 
> Out of curiosity: does this affect images people actually use?
> Examples?

It hit me, so yes. Probably no widespread kernels as Alex' tests looked
fine (not sure what he tests, probably Xen and his OS X bootloader?). In
my case it was a simple test kernel. I'd expect the sum of unknown
research or hobby kernels to be a major use case for Multiboot support,
though.

>> Fix the loading code to pass the whole loaded data to the Multiboot Option ROM.
>>
>> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
>> ---
>>  hw/loader.c |    2 --
>>  hw/pc.c     |   10 ++++++----
>>  2 files changed, 6 insertions(+), 6 deletions(-)
>>
>> diff --git a/hw/loader.c b/hw/loader.c
>> index 2d7a2c4..4c6981f 100644
>> --- a/hw/loader.c
>> +++ b/hw/loader.c
>> @@ -718,8 +718,6 @@ int rom_copy(uint8_t *dest, target_phys_addr_t addr, size_t size)
>>      QTAILQ_FOREACH(rom, &roms, next) {
>>          if (rom->max)
>>              continue;
>> -        if (rom->min > addr)
>> -            continue;
>>          if (rom->min + rom->romsize < addr)
>>              continue;
>>          if (rom->min > end)
> 
> I don't understand this hunk.

The original code assumes that there is only one ROM that contains the
entry point. In fact, each program header of an ELF file becomes it own
ROM, though. So if you have a first PH which contains the entry point
(or now the lowest loaded address) and a second PH at a higher address,
this test would fail for the second one even though we need to load it.

What we really need to test is if [addr, end] and [rom->min, rom->min +
rom->romsize] have an intersection. This is what the following two ifs
already check.

Kevin

  reply	other threads:[~2009-12-16 10:12 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-12-04 16:19 [Qemu-devel] [FOR 0.12][PATCH] Fix loading of ELF multiboot kernels Kevin Wolf
2009-12-16  9:51 ` Markus Armbruster
2009-12-16 10:11   ` Kevin Wolf [this message]
2009-12-16 12:04     ` Markus Armbruster

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=4B28B256.2020605@redhat.com \
    --to=kwolf@redhat.com \
    --cc=agraf@suse.de \
    --cc=armbru@redhat.com \
    --cc=qemu-devel@nongnu.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: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).