From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1LbLgF-00075x-UO for mharc-grub-devel@gnu.org; Sun, 22 Feb 2009 16:16:07 -0500 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LbLgD-00075Z-UQ for grub-devel@gnu.org; Sun, 22 Feb 2009 16:16:05 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LbLgD-00075K-6C for grub-devel@gnu.org; Sun, 22 Feb 2009 16:16:05 -0500 Received: from [199.232.76.173] (port=35567 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LbLgD-00075H-0T for grub-devel@gnu.org; Sun, 22 Feb 2009 16:16:05 -0500 Received: from fg-out-1718.google.com ([72.14.220.153]:47216) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1LbLgC-00012q-Le for grub-devel@gnu.org; Sun, 22 Feb 2009 16:16:04 -0500 Received: by fg-out-1718.google.com with SMTP id l27so1829364fgb.30 for ; Sun, 22 Feb 2009 13:16:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=MbrkmZ0CpHatLWaBJTVRK7GHp6C8PFk4kA/QN9OJXB4=; b=nmQMdWOvCNQKAvpLkXTQ64vEWkDLUAMO2X6AvzwIkRJEJMsmrFJfeCqKjj5EnYE2Ad u4cYM0s1mdmScSOg/gpX9X4y3tVSeiRSyjAEjuTqoNOCloG3Oo7YJNWhaVyxKAjXcDPm s7AeBug4OJ5xJYvUiTzpUS1CMJPzqUg12vw8A= DomainKey-Signature: a=rsa-sha1; c=nofws; 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; b=A/HFQaRSmeIjbhlUY97EdMHt4pFa+kiz7Vbv3KSc5FL0LaKg7c+KfsNJh7joymSuIL ChBNALau2xcBPxBNDc0DFoGLraFU3lCQdFeYi683Vwy7ZMV98cxS1p0FGmDseTmwvmv/ nWtnEIJvVMU+Sd87kUDMYKyCR8jaYwCthHAZ8= Received: by 10.86.59.18 with SMTP id h18mr2493292fga.5.1235337363810; Sun, 22 Feb 2009 13:16:03 -0800 (PST) Received: from ?192.168.1.2? (129-140.3-85.cust.bluewin.ch [85.3.140.129]) by mx.google.com with ESMTPS id 4sm9758571fge.44.2009.02.22.13.16.03 (version=SSLv3 cipher=RC4-MD5); Sun, 22 Feb 2009 13:16:03 -0800 (PST) Message-ID: <49A1C092.5040309@gmail.com> Date: Sun, 22 Feb 2009 22:16:02 +0100 From: phcoder User-Agent: Thunderbird 2.0.0.19 (X11/20090105) 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> In-Reply-To: <49A1A47F.30701@student.ethz.ch> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 2) 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 21:16:06 -0000 > 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 of open developement come in play > > But how do I get it into every possible loader? s/grub_gzio_open(filename, 1)/grub_gnupg_open(filename, GZIO_TRANSPARENT) s/grub_file_open(filename)/grub_gnupg_open(filename, 0) > 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. Then how is your proposition with two file read functions different from 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 > > 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 > > Greets, > > Jan Regards Vladimir 'phcoder' Serbinenko