From: Kevin Wolf <kwolf@redhat.com>
To: Eric Blake <eblake@redhat.com>
Cc: qemu-block@nongnu.org, stefanha@redhat.com, qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [PATCH] qcow2 spec: Describe string header extensions
Date: Fri, 8 Mar 2019 11:27:21 +0100 [thread overview]
Message-ID: <20190308102721.GD5339@localhost.localdomain> (raw)
In-Reply-To: <415d75bd-2d62-d19a-8a5f-e463f4f72866@redhat.com>
[-- Attachment #1: Type: text/plain, Size: 2006 bytes --]
Am 07.03.2019 um 18:40 hat Eric Blake geschrieben:
> On 3/7/19 10:53 AM, Kevin Wolf wrote:
> > Be more specific about the string representation in header extensions.
> >
> > Suggested-by: Stefan Hajnoczi <stefanha@redhat.com>
> > Signed-off-by: Kevin Wolf <kwolf@redhat.com>
> > ---
> > docs/interop/qcow2.txt | 14 ++++++++++++--
> > 1 file changed, 12 insertions(+), 2 deletions(-)
> >
>
> Based-on: <20190227172256.30368-1-kwolf@redhat.com>
>
> >
> >
> > +== String header extensions ==
> > +
> > +Some header extensions (such as the backing file format name and the external
> > +data file name) are just a single string. In this case, the header extension
> > +length is the string length and the string is not '\0' terminated. (The header
> > +extension padding can make it look like a string is '\0' terminated, but
> > +neither is padding always necessary nor is there a guarantee that zero bytes
> > +are used for padding.)
>
> We didn't require 0 padding? (goes and re-reads) - oops, yes that's
> correct.
Yes. QEMU does use zeroes, but the spec doesn't mandate it and changing
it would be an incompatible change. And the worst that could happen is
that someone leaves a hidden message in the padding, which doesn't
really hurt.
> It makes it harder to extend a struct by making use of that
> padding if you can't guarantee what the padding had to be prior to the
> extension, and means that you have to consider whether there are any
> potential security risks of the padding being used as a side channel to
> leak information while still being a well-formed file.
It doesn't actually make it harder because we have the length field
which tells us the exact length of the valid data, so we shouldn't even
try to use any of the padding.
> But changing the standard to require zero padding is different than
> documenting existing practice, so your patch is correct.
>
> Reviewed-by: Eric Blake <eblake@redhat.com>
Thanks!
Kevin
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
next prev parent reply other threads:[~2019-03-08 10:27 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-03-07 16:53 [Qemu-devel] [PATCH] qcow2 spec: Describe string header extensions Kevin Wolf
2019-03-07 17:40 ` Eric Blake
2019-03-08 10:27 ` Kevin Wolf [this message]
2019-03-07 18:15 ` Stefan Hajnoczi
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=20190308102721.GD5339@localhost.localdomain \
--to=kwolf@redhat.com \
--cc=eblake@redhat.com \
--cc=qemu-block@nongnu.org \
--cc=qemu-devel@nongnu.org \
--cc=stefanha@redhat.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).