From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from list by lists.gnu.org with archive (Exim 4.71) id 1RdJcd-0002iy-QR for mharc-grub-devel@gnu.org; Wed, 21 Dec 2011 05:42:07 -0500 Received: from eggs.gnu.org ([140.186.70.92]:41147) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RdJcN-0002UW-Vi for grub-devel@gnu.org; Wed, 21 Dec 2011 05:41:59 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RdJcF-0001fD-TS for grub-devel@gnu.org; Wed, 21 Dec 2011 05:41:51 -0500 Received: from mail-wi0-f169.google.com ([209.85.212.169]:38931) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RdJcF-0001dG-0B for grub-devel@gnu.org; Wed, 21 Dec 2011 05:41:43 -0500 Received: by wibhq12 with SMTP id hq12so2430535wib.0 for ; Wed, 21 Dec 2011 02:41:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=Z+bUm6aFTZBf22Az3uc6k5x097nydWbyxhxcfyh/8M4=; b=FJ0Nsr9VbhVRk+dLI1PZFmHsQ0tnHrFh1F7KAme4mDy7KykP2/ppGaYnIOf/DQZpGe e4eH544ujmsk1fmeBdk2rfmJpy4l2b9KnhZLMSuZ1aFzztuHgX3btYIqezeLld2WXwxx N29UYn7iODSk0s6PbcrFbJe2hnmKHYhFITN8k= Received: by 10.180.107.134 with SMTP id hc6mr10490415wib.21.1324464101502; Wed, 21 Dec 2011 02:41:41 -0800 (PST) Received: from debian.x201.phnet (cx-public-docking-1-027.ethz.ch. [129.132.149.27]) by mx.google.com with ESMTPS id en20sm12394672wid.10.2011.12.21.02.41.38 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 21 Dec 2011 02:41:39 -0800 (PST) Message-ID: <4EF1B7E1.30803@gmail.com> Date: Wed, 21 Dec 2011 11:41:37 +0100 From: =?UTF-8?B?VmxhZGltaXIgJ8+GLWNvZGVyL3BoY29kZXInIFNlcmJpbmVua28=?= User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.24) Gecko/20111114 Icedove/3.1.16 MIME-Version: 1.0 To: grub-devel@gnu.org Subject: Re: does the chainloader command ever return? References: <20111218222435.GF24811@riva.dynamic.greenend.org.uk> In-Reply-To: <20111218222435.GF24811@riva.dynamic.greenend.org.uk> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 2) X-Received-From: 209.85.212.169 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: Wed, 21 Dec 2011 10:41:59 -0000 >> I want a dual-boot system (windows XP/linux) that normally boots the >> windows XP partition, but if that partition is not yet loaded or horribly >> corrupted, I want grub to automatically boot the other (linux) partition. > I suppose it might be possible to come up with some other way to check > the integrity of the Windows XP boot sector. It might involve a custom > GRUB module. > For the case of Windows we can do better than that: we can skip boot sector altogether and load ntldr/bootmgr directly thus bootsector problems other the ones which make partition unreadable (in which case you'll get an FS error) are irrelevant. ntldr/bootmgr isn't thoroughly checked and may be corrupted in which case we're back to running garbage. However it's much less likely for the file with given name on apparently intact FS to be corrupted than the sector 0 of a partition with unknown FS status. This problem isn't unique to ntldr/bootmgr but other payloads are affected as well to various degrees. Whether doing more checks is warranted is unclear. Even perfectly correct image can fail because of corruption in other files or hw issues. While it's theoretically possible to simulate the whole boot to see if it fails, it's not practicable due to effort and boot time needed. Some simple checks would be good provided that they are fast and don't result in false negatives but are unlikely to make difference. Checksums and signatures are another story but unless it's maintained together with or inside the image, it's likely to fail on updates. We could check checksum and signatures on following payloads: -Linux (CRC32) -Solaris (ELF signature) Something else? However signature checking increases the dependencies of loader modules but it's probably small price to pay compared to the risk of loading and running damaged kernel. Bottom line is: you can't check for sure that something will boot, at most you can check that it wasn't damaged after compilation. -- Regards Vladimir 'φ-coder/phcoder' Serbinenko