From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1LbJpx-0006A1-V4 for mharc-grub-devel@gnu.org; Sun, 22 Feb 2009 14:18:01 -0500 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LbJpv-000695-V0 for grub-devel@gnu.org; Sun, 22 Feb 2009 14:17:59 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LbJpu-00068V-CG for grub-devel@gnu.org; Sun, 22 Feb 2009 14:17:59 -0500 Received: from [199.232.76.173] (port=54709 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LbJpu-00068S-6L for grub-devel@gnu.org; Sun, 22 Feb 2009 14:17:58 -0500 Received: from xsmtp0.ethz.ch ([82.130.70.14]:48989) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1LbJpt-0006qR-RZ for grub-devel@gnu.org; Sun, 22 Feb 2009 14:17:58 -0500 Received: from xfe1.d.ethz.ch ([82.130.124.41]) by XSMTP0.ethz.ch with Microsoft SMTPSVC(6.0.3790.3959); Sun, 22 Feb 2009 20:17:56 +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); Sun, 22 Feb 2009 20:17:56 +0100 Message-ID: <49A1A47F.30701@student.ethz.ch> Date: Sun, 22 Feb 2009 20:16:15 +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> In-Reply-To: <49A19D67.2060003@nic.fi> X-Enigmail-Version: 0.95.7 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigECD6E8850AA161433B888DC7" X-OriginalArrivalTime: 22 Feb 2009 19:17:56.0572 (UTC) FILETIME=[4465D1C0:01C99522] 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 19:18:00 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigECD6E8850AA161433B888DC7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Vesa J=E4=E4skel=E4inen wrote: > Jan Alsenz wrote: >> Vesa J=E4=E4skel=E4inen write: >>> I do like the idea what some protected systems use, they sign the bin= ary >>> (in our case .mod file and kernels of loaded OSes). Now in that scena= rio >>> it is responsibility of the kernel module loader to first verify the >>> signature for correctness. This way the signature checking would be >>> somewhat transparent to the rest of the system. >>> >>> I do not see a need to add any hooks to disk read. It should be >>> responsibility of the code needing signature checking to handle that.= >> Well, since to trusted operation should be transparent (and in my opin= ion should >> not need code changes in something like the loaders - so if someone wr= ites a new >> loader, it should work by default), that's where the hooks come in. >> Maybe the "disk read" was misleading, what I meant where "file reads".= >=20 > Hi, >=20 > Well.. you probably don't want to verify authenticity of the fonts or > bitmaps in graphical menu? Oh, I want! If I remember correctly, exactly this broke the protection on some game c= onsole! > Anyway. I think the right place for verification hook in this case is > the module or OS kernel loader. >=20 > If you think otherwise. Then you have to provide a complete technical > design how it should work as I see no other good choice for it. >=20 > (actually there is one other place that could be used, but I let you > come up with the idea after you have given a bit more though on the > implementation side :)) But how do I get it into every possible loader? My current suggestion would be to put a hook possibility into kern/file.c= and extend the fs interface with a function to compare to files, to get rid o= f the double hashing problem mentioned by phcoder. 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. 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 i= s largely impractical. (There might be options with "sparce" hashing - mean= ing only hashing the parts that are actually read, and including the map of r= ead areas into the final hash) Greets, Jan --------------enigECD6E8850AA161433B888DC7 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) iEYEARECAAYFAkmhpIwACgkQfZylhtn4XvcSLwCeK3F9oPB3zCy13N1/TNs/Wxzs ODEAn04OmtThW5Y7SWzpa42R6ucHf2C6 =WlSR -----END PGP SIGNATURE----- --------------enigECD6E8850AA161433B888DC7--