From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from list by lists.gnu.org with archive (Exim 4.71) id 1QXJjg-0008R2-79 for mharc-grub-devel@gnu.org; Thu, 16 Jun 2011 17:04:20 -0400 Received: from eggs.gnu.org ([140.186.70.92]:43786) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QXJjd-0008QR-Ho for grub-devel@gnu.org; Thu, 16 Jun 2011 17:04:18 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QXJjb-0005UU-N1 for grub-devel@gnu.org; Thu, 16 Jun 2011 17:04:17 -0400 Received: from cavan.codon.org.uk ([93.93.128.6]:42250) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QXJjb-0005T5-AK for grub-devel@gnu.org; Thu, 16 Jun 2011 17:04:15 -0400 Received: from mjg59 by cavan.codon.org.uk with local (Exim 4.72) (envelope-from ) id 1QXJjR-0006oi-1S for grub-devel@gnu.org; Thu, 16 Jun 2011 22:04:05 +0100 Date: Thu, 16 Jun 2011 22:04:04 +0100 From: Matthew Garrett To: grub-devel@gnu.org Subject: Issues with Linux loading code Message-ID: <20110616210404.GA26013@srcf.ucam.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.20 (2009-06-14) X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: mjg59@cavan.codon.org.uk X-SA-Exim-Scanned: No (on cavan.codon.org.uk); SAEximRunCond expanded to false X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 2) X-Received-From: 93.93.128.6 X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: The development of GNU GRUB List-Id: The development of GNU GRUB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jun 2011 21:04:18 -0000 I'm currently handling some issues related to the kernel ending up on top of used EFI regions on some machines. These seem to be exacerbated by some of grub's behaviour. It seems that the kernel will always be loaded at GRUB_LINUX_BZIMAGE_ADDR, which is problematic in two cases - one being that the kernel can be configured with a different start address, and also that the firmware may have put code there that we wish to preserve. At present it doesn't seem possible to indicate to the relocator that if there isn't enough space for the decompressed kernel (ie, the init_size parameter from the header) at the desired address, it should put the kernel somewhere else making sure to adhere to the alignment constraints the kernel provides. The load address and the alignment then need to be written back into the kernel header. Or am I misinterpreting the behaviour of the relocation code? -- Matthew Garrett | mjg59@srcf.ucam.org