From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([208.118.235.92]:54260)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <mst@redhat.com>) id 1UMzz4-0006MX-Un
	for qemu-devel@nongnu.org; Tue, 02 Apr 2013 08:06:42 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <mst@redhat.com>) id 1UMzyw-00011G-W7
	for qemu-devel@nongnu.org; Tue, 02 Apr 2013 08:06:38 -0400
Received: from mx1.redhat.com ([209.132.183.28]:6544)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <mst@redhat.com>) id 1UMzyw-000116-OY
	for qemu-devel@nongnu.org; Tue, 02 Apr 2013 08:06:30 -0400
Date: Tue, 2 Apr 2013 15:06:57 +0300
From: "Michael S. Tsirkin" <mst@redhat.com>
Message-ID: <20130402120657.GD21545@redhat.com>
References: <51531A51.3050709@linux.vnet.ibm.com>
	<51532268.40102@linux.vnet.ibm.com> <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>
	<OF20F2D319.6E2B84C9-ON85257B3D.005EB3A1-85257B3D.00606810@us.ibm.com>
	<20130331081728.GH23484@redhat.com>
	<OF5FE8706C.4F902968-ON85257B3F.00709471-85257B3F.00724C73@us.ibm.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <OF5FE8706C.4F902968-ON85257B3F.00709471-85257B3F.00724C73@us.ibm.com>
Subject: Re: [Qemu-devel] vNVRAM / blobstore design
List-Id: <qemu-devel.nongnu.org>
List-Unsubscribe: <https://lists.nongnu.org/mailman/options/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <https://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Kenneth Goldman <kgoldman@us.ibm.com>
Cc: Stefan Berger <stefanb@linux.vnet.ibm.com>, Stefan Hajnoczi <stefanha@gmail.com>, Kent E Yoder <yoder1@us.ibm.com>, Corey Bryant <coreyb@linux.vnet.ibm.com>, Michael Roth <mdroth@linux.vnet.ibm.com>, qemu-devel <qemu-devel@nongnu.org>, Joel Schopp <jschopp@linux.vnet.ibm.com>, Anthony Liguori <anthony@codemonkey.ws>

On Sun, Mar 31, 2013 at 04:48:24PM -0400, Kenneth Goldman wrote:
> "Michael S. Tsirkin" <mst@redhat.com> wrote on 03/31/2013 04:17:28 AM:
> >
> > You want to protect against someone who is able to
> > manipulate some bits in the file (content) but not others (hash)?
> > What's the attack you are trying to protect against here?
> >
> > I'm guessing the only result of extra checksums would be
> > unbootable guests when qemu manages to corrupt the checksum
> > without any help from attackers ...
> 
> 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 ...

-- 
MST