qemu-trivial.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Stefan Hajnoczi <stefanha@gmail.com>
To: Stefan Hajnoczi <stefanha@gmail.com>, Jon Loeliger <jdl@jdl.com>,
	qemu-trivial@nongnu.org, agraf@suse.de, qemu-devel@nongnu.org,
	 Peter Crosthwaite <peter.crosthwaite@petalogix.com>
Subject: Re: [Qemu-trivial] [Qemu-devel] [PATCH] device_tree: load_device_tree(): Allow NULL sizep
Date: Mon, 20 Aug 2012 14:58:39 +0100	[thread overview]
Message-ID: <CAJSP0QUoH0nwyCE+U9b1Ua3oDDKE+nx5h7qS8Lr_TEp=rzHmWA@mail.gmail.com> (raw)
In-Reply-To: <20120816021411.GE4171@truffula.fritz.box>

On Thu, Aug 16, 2012 at 3:14 AM, David Gibson
<david@gibson.dropbear.id.au> wrote:
> On Wed, Aug 15, 2012 at 02:41:56PM +0100, Stefan Hajnoczi wrote:
>> On Sat, Aug 11, 2012 at 01:33:42PM +0100, Stefan Hajnoczi wrote:
>> > On Sat, Aug 11, 2012 at 12:11 AM, Peter Crosthwaite
>> > <peter.crosthwaite@petalogix.com> wrote:
>> > > On Fri, Aug 10, 2012 at 11:42 PM, Stefan Hajnoczi <stefanha@gmail.com> wrote:
>> > >> On Fri, Aug 10, 2012 at 01:54:26PM +1000, Peter A. G. Crosthwaite wrote:
>> > >>> The sizep arg is populated with the size of the loaded device tree. Since this
>> > >>> is one of those informational "please populate" type arguments it should be
>> > >>> optional. Guarded writes to *sizep against NULL accordingly.
>> > >>>
>> > >>> Signed-off-by: Peter A. G. Crosthwaite <peter.crosthwaite@petalogix.com>
>> > >>> Acked-by: Alexander Graf <agraf@suse.de>
>> > >>> ---
>> > >>>  device_tree.c |    8 ++++++--
>> > >>>  1 files changed, 6 insertions(+), 2 deletions(-)
>> > >>>
>> > >>> diff --git a/device_tree.c b/device_tree.c
>> > >>> index d7a9b6b..641a48a 100644
>> > >>> --- a/device_tree.c
>> > >>> +++ b/device_tree.c
>> > >>> @@ -71,7 +71,9 @@ void *load_device_tree(const char *filename_path, int *sizep)
>> > >>>      int ret;
>> > >>>      void *fdt = NULL;
>> > >>>
>> > >>> -    *sizep = 0;
>> > >>> +    if (sizep) {
>> > >>> +        *sizep = 0;
>> > >>> +    }
>> > >>>      dt_size = get_image_size(filename_path);
>> > >>>      if (dt_size < 0) {
>> > >>>          printf("Unable to get size of device tree file '%s'\n",
>> > >>> @@ -104,7 +106,9 @@ void *load_device_tree(const char *filename_path, int *sizep)
>> > >>>              filename_path);
>> > >>>          goto fail;
>> > >>>      }
>> > >>> -    *sizep = dt_size;
>> > >>> +    if (sizep) {
>> > >>> +        *sizep = dt_size;
>> > >>> +    }
>> > >>
>> > >> What can the caller do with this void* buffer without knowing its size?
>> > >>
>> > >
>> > > Sanity check the machine:
>> > >
>> > > dtb = load_device_tree( ... ); //dont care how big it is
>> > > foo = fdt_gep_prop( dtb, ... );
>> > > if (foo != object_get_prop(foo_device, foo_prop, ... )) {
>> > >     hw_error("your dtb is bad because ... !\n", ... );
>> > > }
>> >
>> > What happens if the fdt is corrupt or malicious?  I guess we'll access
>> > memory beyond the end of blob.
>> >
>> > This seems to be libfdt's fault.  I didn't see an API to validate the
>> > blob's size.
>> >
>> > I'm "happy" with this patch but if fdt's can ever come from untrusted
>> > sources then we're in trouble.
>>
>> Jon/David, can you confirm that libfdt has no way of check the size of
>> the fdt blob?
>
> That's not rentirely true.
>
>> For example, if I pass a corrupt or malicious blob to libfdt, is there a
>> way to detect that or will it access memory beyond the end of the blob
>> as we query the device tree?
>
> So, libfdt does trust the blob size that's given in the blob header,
> since libfdt itself doesn't really have any other source for the
> blob/buffer size.  If you have another source for your buffer size
> though, you can check that quite easily against fdt_totalsize(blob)
> (which returns the header value).  If you can think of a helper
> function that would make this easier, I'd be happy to add it to
> libfdt.
>
> Once the header size is validated, though, libfdt *is* supposed to be
> safe against a corrupt or malicious blob.  I can't guarantee that we
> don't have bugs here, but any crash on malicious data I do consider a
> bug and will fix once I'm aware of it.

David:

fdt_check_header() does not check off_dt_struct, off_dt_strings,
off_mem_rsvmap, size_dt_strings, size_dt_struct against the blob size.
 For example, fdt_get_mem_rsv() will access out-of-bounds memory if
off_mem_rsvmap is invalid.  Or another example, fdt_offset_ptr() does
bounds checking on offset + len but only against the size_dt_struct
header field, which was never checked against the blob size.

Having the user check fdt_totalsize(blob) is not enough.  libfdt
itself needs to use the blob's external size to validate the fdt
header.  Something like:

/**
 * fdt_check_header_size - sanity check a device tree's size
 * @fdt: pointer to a flattened device tree
 * @size: fdt size in bytes
 *
 * fdt_check_header_size() checks that the given flattened
 * device tree header describes a data layout that fits within
 * the given size limit.  Use this to check untrusted fdt input
 * immediately after calling fdt_check_header() and before calling
 * other functions.
 *
 * returns:
 *     0, if the fdt fits within the given size limit
 *     -FDT_ERR_NOSPACE, fdt would exceed given size
 *     -FDT_ERR_BADMAGIC,
 *     -FDT_ERR_BADVERSION, standard meanings
 */
int fdt_check_blob_size(const void *fdt, size_t size);

Also, fdt_string() documentation says the function returns NULL if
stroffset is out of bounds.  The implementation does not check and
will return an out-of-bounds pointer.

Peter:

When libfdt adds the fdt_check_block_size() function then the QEMU
patch is no longer useful since the header size should be validate
(this requires a non-NULL size argument).  I suggest we drop the
patch.

Stefan


      reply	other threads:[~2012-08-20 13:58 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-08-10  3:54 [Qemu-trivial] [PULL 0/1] device_tree: load_device_tree(): Allow NULL sizep Peter A. G. Crosthwaite
2012-08-10  3:54 ` [Qemu-trivial] [PATCH] " Peter A. G. Crosthwaite
2012-08-10 13:42   ` [Qemu-trivial] [Qemu-devel] " Stefan Hajnoczi
2012-08-10 23:11     ` Peter Crosthwaite
2012-08-11 12:33       ` Stefan Hajnoczi
2012-08-15 13:41         ` Stefan Hajnoczi
2012-08-16  2:14           ` David Gibson
2012-08-20 13:58             ` Stefan Hajnoczi [this message]

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='CAJSP0QUoH0nwyCE+U9b1Ua3oDDKE+nx5h7qS8Lr_TEp=rzHmWA@mail.gmail.com' \
    --to=stefanha@gmail.com \
    --cc=agraf@suse.de \
    --cc=jdl@jdl.com \
    --cc=peter.crosthwaite@petalogix.com \
    --cc=qemu-devel@nongnu.org \
    --cc=qemu-trivial@nongnu.org \
    /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).