From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:53016) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UN1PT-0003qn-R7 for qemu-devel@nongnu.org; Tue, 02 Apr 2013 09:38:02 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UN1PR-0000Zk-5j for qemu-devel@nongnu.org; Tue, 02 Apr 2013 09:37:59 -0400 Received: from mx1.redhat.com ([209.132.183.28]:8856) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UN1PQ-0000Zc-SR for qemu-devel@nongnu.org; Tue, 02 Apr 2013 09:37:57 -0400 Date: Tue, 2 Apr 2013 16:37:25 +0300 From: "Michael S. Tsirkin" Message-ID: <20130402133725.GL21545@redhat.com> References: <87k3os7okn.fsf@codemonkey.ws> <51532C0B.1050108@linux.vnet.ibm.com> <87ehf03dgw.fsf@codemonkey.ws> <515344AB.2030403@linux.vnet.ibm.com> <51546BAA.60504@linux.vnet.ibm.com> <20130331081728.GH23484@redhat.com> <20130402120657.GD21545@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Subject: Re: [Qemu-devel] vNVRAM / blobstore design List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Kenneth Goldman Cc: Stefan Berger , Stefan Hajnoczi , Kent E Yoder , Corey Bryant , Michael Roth , qemu-devel , Joel Schopp , Anthony Liguori On Tue, Apr 02, 2013 at 09:24:51AM -0400, Kenneth Goldman wrote: > > > You are of course correct. I advised an integrity value just to detect > > > a hardware or software fault. The check value would not protect against an > > > attack. > > > > Fair enough, but why protect these bits specifically? > > E.g. disk corruption seems more likely (since it's bigger). Add > > integrity at that level? Why even stop at detection, let's do error > > correction ... > > Why ... just because it's a security device. Whenever I code for security, This is virtualization. Everything is for security here. > I add layers of protection, constantly looking for "this should never happen" > cases. Confused. You said this checksum is for integrity not protection ... > It might be just a small benefit, but hashing a few kbytes is a small part > of TPM startup time, and the function is already there. You are ignoring atomicity issues this can introduce in case of e.g. host or qemu crash. Most likely, the result just will be data loss in a situation which would be recoverable otherwise. The reverse of what you were trying to achieve. > Think of it as part > of the larger (and required) TPM self test that a TPM must do. Required? -- MST