All of lore.kernel.org
 help / color / mirror / Atom feed
From: Hollis Blanchard <hollis@penguinppc.org>
To: The development of GRUB 2 <grub-devel@gnu.org>
Subject: Re: [PATCH] generic ELF loading
Date: Tue, 24 Oct 2006 15:45:22 -0500	[thread overview]
Message-ID: <1161722722.23331.46.camel@basalt.austin.ibm.com> (raw)
In-Reply-To: <87iri91lug.fsf@night.trouble.net>

On Tue, 2006-10-24 at 22:48 +0200, Johan Rydberg wrote:
> Hollis Blanchard <hollis@penguinppc.org> writes:
> 
> >> The idea is very good. But I don't like that loaded areas are always allocated 
> >> from the heap. GRUB has a staging area for OS images on i386-pc, and I prefer 
> >> to load an image directly instead of consuming the heap.
> >
> > Actually I'm not using the heap, I'm just directly copying wherever
> > phdr->p_paddr says to. That's not a good thing actually; in the future
> > we should add some error checking to make sure we don't clobber GRUB
> > itself.
> 
> Have you looked at how EFI solves this?  
> 
> They keep track of all memory regions, and with each region is a
> "memory type" associated.  Whenever you allocate memory you change the
> type of the region (from "free") to some that makes sense (could be
> "loader data", "disk cache", ...). You can only allocate memory that
> is marked "conventional", meaning it is considered free.  The memory
> region database is later feed to the operating system.  We could do
> the same.
> 
> Is this case we could allocate the regions specified by the ELF image.
> If any of the allocations fail we know there is something already
> loaded there, or the image is faulty.

That's a great point. Doing a "claim" (as described in my reply to
Tristan) will return an error if the area is already claimed, so that
will accomplish the check.

On x86, the load hook will manually check to make sure the address is
within the OS load area.

-Hollis




  reply	other threads:[~2006-10-24 20:45 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-10-13 22:37 [PATCH] generic ELF loading Hollis Blanchard
2006-10-13 22:40 ` [PATCH] ppc64 Linux ELF loader Hollis Blanchard
2006-10-14 15:33 ` [PATCH] generic ELF loading Yoshinori K. Okuji
2006-10-14 17:23   ` Tristan Gingold
2006-10-24 20:41     ` Hollis Blanchard
2006-10-24 20:03   ` Hollis Blanchard
2006-10-24 20:48     ` Johan Rydberg
2006-10-24 20:45       ` Hollis Blanchard [this message]
2006-10-25  5:53     ` Yoshinori K. Okuji
  -- strict thread matches above, loose matches on Subject: below --
2006-10-14  3:03 Mao, Bibo
2006-10-24 20:21 ` Hollis Blanchard

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=1161722722.23331.46.camel@basalt.austin.ibm.com \
    --to=hollis@penguinppc.org \
    --cc=grub-devel@gnu.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 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.