From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1MJvbJ-0008CU-VW for mharc-grub-devel@gnu.org; Thu, 25 Jun 2009 16:31:18 -0400 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MJvbI-0008CP-4q for grub-devel@gnu.org; Thu, 25 Jun 2009 16:31:16 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MJvbD-0008C5-Ka for grub-devel@gnu.org; Thu, 25 Jun 2009 16:31:15 -0400 Received: from [199.232.76.173] (port=48309 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MJvbD-0008C2-Du for grub-devel@gnu.org; Thu, 25 Jun 2009 16:31:11 -0400 Received: from aybabtu.com ([69.60.117.155]:33150) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1MJvbC-0005Zd-TP for grub-devel@gnu.org; Thu, 25 Jun 2009 16:31:11 -0400 Received: from [192.168.10.10] (helo=thorin) by aybabtu.com with esmtp (Exim 4.69) (envelope-from ) id 1MJuXu-0001Uu-KQ for grub-devel@gnu.org; Thu, 25 Jun 2009 21:23:43 +0200 Received: from rmh by thorin with local (Exim 4.69) (envelope-from ) id 1MJvbA-0001D8-7L for grub-devel@gnu.org; Thu, 25 Jun 2009 22:31:08 +0200 Date: Thu, 25 Jun 2009 22:31:08 +0200 From: Robert Millan To: The development of GRUB 2 Message-ID: <20090625203108.GB4344@thorin> References: <20090621181748.GA21152@thorin> <20090622230751.GD11998@thorin> <1245720581.30815.11.camel@mj> <20090623113850.GB24028@thorin> <20090623121325.GA3130@thorin> <20090624010032.GA19305@thorin> <20090624231005.GA30986@thorin> <1245959608.18261.64.camel@mj> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1245959608.18261.64.camel@mj> Organization: free as in freedom X-Message-Flag: Worried about Outlook viruses? Switch to Thunderbird! www.mozilla.com/thunderbird X-Debbugs-No-Ack: true User-Agent: Mutt/1.5.18 (2008-05-17) X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 1) Subject: Re: [PATCH] fix for loading modules from read-only memory area (Re: clean patch for i386-qemu port (Re: [PATCH] i386-qemu port)) X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: The development of GRUB 2 List-Id: The development of GRUB 2 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jun 2009 20:31:16 -0000 On Thu, Jun 25, 2009 at 03:53:28PM -0400, Pavel Roskin wrote: > On Thu, 2009-06-25 at 01:10 +0200, Robert Millan wrote: > > On Wed, Jun 24, 2009 at 03:00:32AM +0200, Robert Millan wrote: > > > A possible solution to this could be to make grub_dl_load_core() create a > > > copy of the module and work on the copy. This could even be ifdef'ed, > > > but I doubt the performance hit would be significant. > > > > I found a better approach; instead of copiing the whole module, we just > > need to copy the symbol tab. A small adjustment to each of the functions > > that will access it (grub_dl_resolve_symbols and > > grub_arch_dl_relocate_symbols) will make them use the copy instead of > > the original. > > Massive use of undef seems inelegant. Maybe it's better to use > distinctive names instead, e.g. target_Elf_Ehdr v.s. host_Elf_Ehdr? You mean for efiemu? Seems fine. But I wouldn't use "target/host" naming, since it doesn't match with existing usage of those names elsewhere, which makes it very confusing. How about "native/cross"? > Also, I'm getting many warnings on i386-pc about redefined Elf_Ehdr when > compiling on x86_64. I'll have a look. > Generally, I like the idea for i386-qemu, but for other architectures, > the only change is the increased memory consumption. I would be willing > to accept this change if you could suggest some universal benefit for > all platforms. > > Otherwise, it would be better to use wrappers like get_header() and > put_header() what would do grub_malloc() and grub_free() only if needed > and return the original header otherwise. > > I'm fine with adding the symtab field unconditionally, it doesn't cost > much memory. I agree there's no point in making all architectures do this. However, note that we'll probably see more architectures with read-only modules in the future (other qemu ports, but also any port where GRUB runs standalone). I was thinking that we could just #ifdef the symtab allocation (and the symtab field declaration as well). Since it's just a few lines, I think it'll look readable. -- Robert Millan The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and how) you may access your data; but nobody's threatening your freedom: we still allow you to remove your data and not access it at all."