From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from list by lists.gnu.org with archive (Exim 4.71) id 1U7jeM-0002ti-1F for mharc-grub-devel@gnu.org; Tue, 19 Feb 2013 04:38:10 -0500 Received: from eggs.gnu.org ([208.118.235.92]:52608) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1U7jeD-0002qn-Be for grub-devel@gnu.org; Tue, 19 Feb 2013 04:38:08 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1U7jeB-0000bx-V0 for grub-devel@gnu.org; Tue, 19 Feb 2013 04:38:01 -0500 Received: from mail-wg0-f48.google.com ([74.125.82.48]:55769) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1U7jeB-0000br-Nz for grub-devel@gnu.org; Tue, 19 Feb 2013 04:37:59 -0500 Received: by mail-wg0-f48.google.com with SMTP id 16so5347906wgi.27 for ; Tue, 19 Feb 2013 01:37:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:x-enigmail-version:content-type; bh=pRGBl8GV13eJNffUdko3GBculne16TUMZObePbTcUCQ=; b=mGuzI+0uLiR7FAjQttEJXz245T/L9FPm0fmI2dkUfXJd5KZXWdgSS5vgGJ1CZ55vnU 4cwy1fg0GaTY7uTWDmC1WfFclKaNFeB6BfWQ8KwPpFK2RGSzaenhyrQPYYInSJoitPez Zld3hMMnXBjv0sGD+Wj7kuihYVruzCy+7wU+lOO/sKZyT/VTl/wznDxNm189vAQOCOeU ftbEGl/l3S5pA+23dgzDbkhV+u5PdbQ4FlBlLMKN5k6uvz0LnkJtr9NG4RbNxbqW+/02 YzQqBZrOzvFTS/NWfCj+iYgpxNFSzIToED2yLKElNinFNPlOMycBfZ88bhglas8QP4qp vxhQ== X-Received: by 10.194.9.166 with SMTP id a6mr24964517wjb.2.1361266678698; Tue, 19 Feb 2013 01:37:58 -0800 (PST) Received: from debian.x201.phnet ([217.193.148.98]) by mx.google.com with ESMTPS id bj9sm24449744wib.4.2013.02.19.01.37.57 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 19 Feb 2013 01:37:57 -0800 (PST) Message-ID: <512347F2.4070901@gmail.com> Date: Tue, 19 Feb 2013 10:37:54 +0100 From: =?UTF-8?B?VmxhZGltaXIgJ8+GLWNvZGVyL3BoY29kZXInIFNlcmJpbmVua28=?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.12) Gecko/20130116 Icedove/10.0.12 MIME-Version: 1.0 To: The development of GNU GRUB Subject: Re: GRUB and the risk of block list corruption in extX References: <51138645.4050405@ts.fujitsu.com> <51153345.2020509@ts.fujitsu.com> <0088990F-66E5-4F51-A9C4-3BD8963A6DA0@colorremedies.com> <512261FE.2090604@ts.fujitsu.com> In-Reply-To: X-Enigmail-Version: 1.4.1 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="------------enigC5C7EF855C71CEAC21192A97" X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x [fuzzy] X-Received-From: 74.125.82.48 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: Tue, 19 Feb 2013 09:38:08 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigC5C7EF855C71CEAC21192A97 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I haven't gone through this whole thread yet but this is one of problems with blocklist installs: Suppose blocklist changes because of e.g. user mistake. Yet at the old location there is still the old core.img. For the time being. So this problem may go unnoticed for years yet if someone has the ability to create new files on the disk in question, he creates ton of files with copies of malicious sector, one of them will overwrite core and be executed on next reboot. This is a securitxy problem coming from the fact that in normal environment blocklists are abstracted away into files and are no longer either visible or considered, yet they are still manipulated. embedding zone doesn't have this problem since it's by definition never manipulated= =2E Another trouble is that ext4 devs control only their own implementation. But there are several more floating around. Once we had problems because hurd ext2 behaviour is different from Linux one. Additionally, as long as behaviour of not modifying blocklists of core.img isn't specified as official implementations which would do so (specifically the cow flavours) are within their rights. It's possible to add ext4 parsing to boot sector but it's not sure that it will be maintainable in face of new ext* features. A possibility is to use 2 unused sectors in front of ext* to store initial stage but it doesn't help if embedding isn't available for other reasons than installing to partition. Having embedded zone described by an inode is unusual but is usable as long as: 1) special sector allocation. It must be (at least, preferably more) 4K-aligned (necessary for supporting 4K-sector disks) and contiguous. Either: 2a) miniature parser in boot.S to find this file. Greatly simplified if inode is fixed, since fs parameters are fixed it would be a straightforward of value read. 2b) immutability of blocklist. This also implies that this file can't be shrunk or deleted. --------------enigC5C7EF855C71CEAC21192A97 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iF4EAREKAAYFAlEjR/MACgkQNak7dOguQglNOQD/Ywn8Rvbq/AfZtifT94eWMp2C 3kq3yguTaIyNn7FDdx8A/ilsIkFf/3mJ+sDVXJQGYM5uh+ZDvNQQevPujDZa7K/s =d91z -----END PGP SIGNATURE----- --------------enigC5C7EF855C71CEAC21192A97--