From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from list by lists.gnu.org with archive (Exim 4.71) id 1V2NdX-0002yM-3p for mharc-grub-devel@gnu.org; Thu, 25 Jul 2013 11:39:27 -0400 Received: from eggs.gnu.org ([2001:4830:134:3::10]:60677) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1V2NdT-0002qq-Nw for grub-devel@gnu.org; Thu, 25 Jul 2013 11:39:25 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1V2NdR-0002T3-TA for grub-devel@gnu.org; Thu, 25 Jul 2013 11:39:23 -0400 Received: from mail-wg0-x22f.google.com ([2a00:1450:400c:c00::22f]:39860) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1V2NTc-0007Rg-87 for grub-devel@gnu.org; Thu, 25 Jul 2013 11:29:12 -0400 Received: by mail-wg0-f47.google.com with SMTP id j13so1766400wgh.2 for ; Thu, 25 Jul 2013 08:29:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=TiazMUYy0fMs0c3jI4Va8uIaT0GSssTpJRKCEK+nTfY=; b=JODIXdvfXDJe5MF5PuzizpMV3tNCkR1yLUlkN9Wguq6Jw+KKQHhom+Aq3l4vpSB3im 6HUa9SYVg9QCi5zj5OHZ9MPF64lAoWwbTLQy0yuXfzmnx9+o63HLfVg2lPUX0I1pbC9M LGeY8rMw+NauuCrCy+pmLDgSjKnrdrviVPGYSlzuBMwS1wbUAgNNr6ofqka93DA+zra5 Fv3gbx47BXVxl2WpMPpFyYR2hYWWq8dUmXc7191M3anGLgKGw3ta9rkOdlY7RPqUFFlb zFiLA8BExEj4gZsp/D95YLT+wo32vPnCsSa+a+0AmIN/0KjnSzi3QiuhnMa9+jN0JhCB D4gg== X-Received: by 10.180.107.167 with SMTP id hd7mr2490113wib.33.1374766151555; Thu, 25 Jul 2013 08:29:11 -0700 (PDT) Received: from [192.168.1.113] (31-249.1-85.cust.bluewin.ch. [85.1.249.31]) by mx.google.com with ESMTPSA id nb12sm4489080wic.7.2013.07.25.08.29.10 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 25 Jul 2013 08:29:10 -0700 (PDT) Message-ID: <51F14448.2050103@gmail.com> Date: Thu, 25 Jul 2013 17:29:12 +0200 From: =?UTF-8?B?VmxhZGltaXIgJ8+GLWNvZGVyL3BoY29kZXInIFNlcmJpbmVua28=?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130630 Icedove/17.0.7 MIME-Version: 1.0 To: "Dr. Tilmann Bubeck" , The development of GRUB 2 Subject: Re: Why special linux code in grub2/util/grub-setup.c References: <8513f87fd2e877871174acaf00583071.squirrel@bubecks.de> <51DFAAB0.2040908@gmail.com> <51DFF9EC.7010801@bubecks.de> In-Reply-To: <51DFF9EC.7010801@bubecks.de> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2a00:1450:400c:c00::22f 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, 25 Jul 2013 15:39:25 -0000 On 12.07.2013 14:43, Dr. Tilmann Bubeck wrote: > Hi Vladimir, > > Am 12.07.2013 09:05, schrieb Vladimir 'φ-coder/phcoder' Serbinenko: >> On 12.07.2013 08:52, Dr. Tilmann Bubeck wrote: >>> Hi Vladimir, >>> >>> I am curently preparing an improvement for GRUB2 to let it embed into >>> ext4 >>> based upon the new ioctl EXT4_IOC_SWAP_BOOT which I wrote for linux >>> 3.10. >>> This would allow to install GRUB SAFELY into a file system and omit the >>> warning about block list being unreliable (for ext4). >>> >> What does this ioctl do? > > It was discussed with Ted T'so and modelled after his suggestion and > included in 3.10. It takes the file associated with the file descriptor > passed to the ioctl and stores the data blocks of that file in a special > (reserved) inode called "BOOT_IMAGE_INO". This inode is reserved > specifically for storing boot loaders inside the filesystem. Technically > it copies the inodes data block pointers and some more data like > timestamps from the given file's inode to the BOOT_IMAGE_INO. > > This means, that we have a reserved area for storing the boot file and > that area is never touched again and therefore "sealed". No user tool is > able to get access to that data (except debug2fs and similar). It is not > visible in any directory and not destroyed or reported by e2fsck. It is > similar to the reserved area for booting in btrfs. > > It is called "SWAP", because the previous content of the BOOT_IMAGE_INO > is linked back to the given fd. Therefore one is able to get the > previous boot code in exchange. GRUB would delete that right away. > > Using this ioctl we could make ext4 able to embed reliably which would > allow installing GRUB into a partition without requiring "--force". > >>> To do so I need code to get the blocks of a file. I found that this is >>> already present in grub2/util/grub-setup.c. I have a few questons based >>> upon your changes in revision 4033. >>> >>> 1. Why did you add additional (linux only) methods to get block list >>> based >>> upon FS_IOC_FIEMAP and FIBMAP instead of sticking with the existing >>> (generic) code based upon file->read_hook = save_blocklists? >>> >> Because Linux buffering and caching is piece of shit and even issuing >> flush, sync and flushing ioctl doesn't make metadata go to disk. > > >>> 2. I would like to refactor the above code, so that there is a new >>> method >>> called "grub_getblocklist(dir, core_file, &blocklist);". This method >>> move >>> contain your code together with the generic code to find the blocklist. >>> This method would then be called from the existing place (and my new >>> place >>> in fs/ext2.c if GRUB_UTIL). >>> >>> What do you think? >>> >> Relying on blocklist retrieving is likely wrong and doesn't solve any >> of blocklist problems. But I lack details to know for sure and right now >> I'm under a lot of stress with my thesis on neural learning. > > I would use the blocklist of the above BOOT_IMAGE_INO which will never > change and therefore will never break. However, I need a way to know > where the blocks are stored, even if they are "save". > > Would you accept a patch from me, using the above IOCTL to make > embedding to ext4 work reliable? Sure, we have to discuss the details > but before I start I would like to get a feeling, if this would have a > chance for inclusion. > What's with the allocation issues? The blocks have to be as near to the beginning as possible. Is it possible to modify the embedding zone without doing the "swapping"? There is a parallel issues in LVM which would prompt for the ability of overwrite only part of embedded zone. > A long discussion about GRUBs inability to install into a partition > without using "--force" which is 1 reason for Fedora to switch to > extlinux for this use case can be found in > https://bugzilla.redhat.com/show_bug.cgi?id=872826. > There is a multiboot wrapper for truecrypt and in future it should be integrated in GRUB. Just Truecrypt is considered as low priority not in the least because Fedora included it in the list of forbidden software > Kind regards, > Till >