From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1LbNOt-0008Op-2J for mharc-grub-devel@gnu.org; Sun, 22 Feb 2009 18:06:19 -0500 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LbNOr-0008Oc-6s for grub-devel@gnu.org; Sun, 22 Feb 2009 18:06:17 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LbNOq-0008OL-Id for grub-devel@gnu.org; Sun, 22 Feb 2009 18:06:16 -0500 Received: from [199.232.76.173] (port=34354 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LbNOq-0008OI-FW for grub-devel@gnu.org; Sun, 22 Feb 2009 18:06:16 -0500 Received: from xsmtp1.ethz.ch ([82.130.70.13]:32689) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1LbNOp-0004fq-Uv for grub-devel@gnu.org; Sun, 22 Feb 2009 18:06:16 -0500 Received: from xfe1.d.ethz.ch ([82.130.124.41]) by xsmtp1.ethz.ch with Microsoft SMTPSVC(6.0.3790.3959); Mon, 23 Feb 2009 00:06:14 +0100 Received: from [192.168.2.71] ([81.221.97.38]) by xfe1.d.ethz.ch over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Mon, 23 Feb 2009 00:06:14 +0100 Message-ID: <49A1DA09.7080601@student.ethz.ch> Date: Mon, 23 Feb 2009 00:04:41 +0100 From: Jan Alsenz User-Agent: Thunderbird 2.0.0.19 (X11/20090104) MIME-Version: 1.0 To: The development of GRUB 2 References: <49A152BD.6010907@student.ethz.ch> <49A1782B.3010000@nic.fi> <49A19A05.6030606@student.ethz.ch> <49A19D67.2060003@nic.fi> <49A1A47F.30701@student.ethz.ch> <49A1C092.5040309@gmail.com> In-Reply-To: <49A1C092.5040309@gmail.com> X-Enigmail-Version: 0.95.7 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig0308823A858569F5BC71BC5D" X-OriginalArrivalTime: 22 Feb 2009 23:06:14.0616 (UTC) FILETIME=[29117580:01C99542] X-detected-operating-system: by monty-python.gnu.org: Windows 2000 SP4, XP SP1+ Subject: Re: GRUB trusted boot framework 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: Sun, 22 Feb 2009 23:06:17 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig0308823A858569F5BC71BC5D Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable phcoder wrote: >> Oh, I want! >> If I remember correctly, exactly this broke the protection on some >> game console! > Do you refer to Xbox crack based on King kong game? For once their goal= > is the evil one. For second the problem is a buffer overflow in > rendering engine, not the not checking part. If you want to make a > secure system it must be free of such bugs. Or you may as well hash the= > whole hd and be hacked through network code. Here is where advantages o= f > open developement come in play It is totally irrelevant, if the purpose is good or evil, if it can break= the system. And since it is awfully difficult to produce bug free code, the goal must= be to reduce the code that has to be bug free to the absolute (and openly known= ) minimum: In this case I'd say the reasonable choice is the fs driver code= =2E >> But how do I get it into every possible loader? > s/grub_gzio_open(filename, 1)/grub_gnupg_open(filename, GZIO_TRANSPAREN= T) > s/grub_file_open(filename)/grub_gnupg_open(filename, 0) With "every possible loader", I wanted to include unknown future loaders.= >> I also checked the loopback code and it uses the standard >> grub_file_read, so for >> these cases a read version without a hook would be needed. >=20 > Then how is your proposition with two file read functions different fro= m > mine with two file read functions? What can be proposed is to merge > somehow all opening functions into one with following protype > grub_file_open (const char *filename, int flags, struct grub_file_info > *info) > Then on opening the function will do the default behavior with possible= > override possible through flags. It has an advantage of future > expandability for possible new transparent transformations That would be a good idea. The difference between your and my solution was, that mine it had secure = as default. I'm not yet sure about the flag solution though. If we want to keep the solution general - which I would prefer - the flag= is only known to the transformation and the code who wants to avoid it. To clarify: I'm thinking about a general hook/transformation solution in kern/file.c = =2E Everyone can register a hook there, and now the goal of the flags is, to selectively enable or disable hooks. Problem is, that these hooks are not necessarily all known to all compone= nts. My first thought for a solution was something like: - Every hook gets an unique ID (distribution controlled e.g. via wiki) - The flags are lists of these IDs - A hook can by default be active or inactive - (It may be useful to have some order within the hooks) Apart from solving the problem, this solution would have a few other adva= ntages: - Existing filters, like gzio, could be ported to this generic framework - IDs could be grouped into classes, e.g. to say "I don't want any securi= ty hooks on this operation" for the loopback device I'm not yet happy with the flag-list implementation, so if someone has a = better idea, I would be happy to hear it. >> By the way we're assuming here, that every file-system driver is free = of >> exploitable bugs! >> To avoid this a real disk read hook would be needed, but of course >> that is >> largely impractical. (There might be options with "sparce" hashing - >> meaning >> only hashing the parts that are actually read, and including the map >> of read >> areas into the final hash) > And then after a minor write or fs self-maintenance it suddenly stops > working. You may as well not boot at all. Perfectly secure booter in 2 > bytes of x86-assembly: > eb fe : self: jmp self That's also part of what I meant with "largely impractical" ;) Greets, Jan --------------enig0308823A858569F5BC71BC5D Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkmh2g8ACgkQfZylhtn4XvcM8QCfYDCsNwbYdYpB5AE3QPOBDzH4 MWgAoMxhcS2v+SPCCr9+NLggOuBNr3lb =qjq3 -----END PGP SIGNATURE----- --------------enig0308823A858569F5BC71BC5D--