From: "Michael S. Tsirkin" <mst@redhat.com>
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>
Subject: Re: [Qemu-devel] vNVRAM / blobstore design
Date: Tue, 2 Apr 2013 15:06:57 +0300 [thread overview]
Message-ID: <20130402120657.GD21545@redhat.com> (raw)
In-Reply-To: <OF5FE8706C.4F902968-ON85257B3F.00709471-85257B3F.00724C73@us.ibm.com>
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
next prev parent reply other threads:[~2013-04-02 12:06 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-03-25 21:39 [Qemu-devel] vNVRAM / blobstore design Stefan Berger
2013-03-25 22:05 ` Anthony Liguori
2013-03-25 22:20 ` Stefan Berger
2013-03-27 15:17 ` Corey Bryant
2013-03-27 15:20 ` Corey Bryant
2013-03-27 15:30 ` Michael S. Tsirkin
2013-03-27 16:07 ` mdroth
2013-03-27 15:43 ` Kenneth Goldman
2013-03-27 15:53 ` Michael S. Tsirkin
2013-03-27 16:12 ` Joel Schopp
2013-03-27 16:46 ` Stefan Berger
2013-03-27 17:14 ` Anthony Liguori
2013-03-27 17:27 ` Stefan Berger
2013-03-27 18:27 ` Anthony Liguori
2013-03-27 19:12 ` Stefan Berger
2013-03-28 16:11 ` Stefan Berger
2013-03-28 16:31 ` Michael S. Tsirkin
2013-03-28 17:02 ` Stefan Berger
2013-03-28 17:27 ` Anthony Liguori
2013-03-28 17:36 ` Stefan Berger
2013-03-28 17:39 ` Michael S. Tsirkin
2013-03-29 13:55 ` Stefan Berger
2013-03-29 15:12 ` Anthony Liguori
2013-03-29 17:33 ` Kenneth Goldman
2013-03-31 8:17 ` Michael S. Tsirkin
2013-03-31 20:48 ` Kenneth Goldman
2013-04-02 12:06 ` Michael S. Tsirkin [this message]
2013-04-02 13:24 ` Kenneth Goldman
2013-04-02 13:37 ` Michael S. Tsirkin
2013-03-27 18:04 ` Michael S. Tsirkin
2013-03-27 16:20 ` Kenneth Goldman
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20130402120657.GD21545@redhat.com \
--to=mst@redhat.com \
--cc=anthony@codemonkey.ws \
--cc=coreyb@linux.vnet.ibm.com \
--cc=jschopp@linux.vnet.ibm.com \
--cc=kgoldman@us.ibm.com \
--cc=mdroth@linux.vnet.ibm.com \
--cc=qemu-devel@nongnu.org \
--cc=stefanb@linux.vnet.ibm.com \
--cc=stefanha@gmail.com \
--cc=yoder1@us.ibm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).