Skip to content

Q
qemu

openeuler / qemu

通知 10
Star 0
Fork 0
Q
qemu

体验新版 GitCode，发现更多精彩内容 >>

切换分支/标签
  1. 30 4月, 2014 1 次提交
  3. 22 4月, 2014 1 次提交
  5. 01 4月, 2014 1 次提交
  7. 22 2月, 2014 1 次提交
  9. 18 2月, 2014 1 次提交
  11. 24 1月, 2014 1 次提交
  13. 07 1月, 2014 1 次提交
  15. 12 9月, 2013 1 次提交
  17. 01 9月, 2013 1 次提交
  19. 19 8月, 2013 2 次提交
  21. 05 7月, 2013 1 次提交
    • F
      curl: refuse to open URL from HTTP server without range support · 3494d650
      由 Fam Zheng 提交于 
      CURL driver requests partial data from server on guest IO req. For HTTP
and HTTPS, it uses "Range: ***" in requests, and this will not work if
server not accepting range. This patch does this check when open.

 * Removed curl_size_cb, which is not used: On one hand it's registered to
   libcurl as CURLOPT_WRITEFUNCTION, instead of CURLOPT_HEADERFUNCTION,
   which will get called with *data*, not *header*. On the other hand the
   s->len is assigned unconditionally later.

   In this gone function, the sscanf for "Content-Length: %zd", on
   (void *)ptr, which is not guaranteed to be zero-terminated, is
   potentially a security bug. So this patch fixes it as a side-effect. The
   bug is reported as: https://bugs.launchpad.net/qemu/+bug/1188943
   (Note the bug is marked "private" so you might not be able to see it)

 * Introduced curl_header_cb, which is used to parse header and mark the
   server as accepting range if "Accept-Ranges: bytes" line is seen from
   response header. If protocol is HTTP or HTTPS, but server response has
   no not this support, refuse to open this URL.

Note that python builtin module SimpleHTTPServer is an example of not
supporting range, if you need to test this driver, get a better server
or use internet URLs.
Signed-off-by: NFam Zheng <famz@redhat.com>
Signed-off-by: NStefan Hajnoczi <stefanha@redhat.com>
      3494d650
  23. 17 6月, 2013 2 次提交
  25. 12 6月, 2013 1 次提交
  27. 22 4月, 2013 2 次提交
  29. 23 3月, 2013 1 次提交
  31. 14 2月, 2013 1 次提交
  33. 09 2月, 2013 1 次提交
  35. 19 12月, 2012 1 次提交
  37. 15 11月, 2012 1 次提交
  39. 12 9月, 2012 1 次提交
  41. 12 6月, 2012 1 次提交
    • M
      allow qemu_iovec_from_buffer() to specify offset from which to start copying · 03396148
      由 Michael Tokarev 提交于 
      Similar to
 qemu_iovec_memset(QEMUIOVector *qiov, size_t offset,
                   int c, size_t bytes);
the new prototype is:
 qemu_iovec_from_buf(QEMUIOVector *qiov, size_t offset,
                     const void *buf, size_t bytes);

The processing starts at offset bytes within qiov.

This way, we may copy a bounce buffer directly to
a middle of qiov.

This is exactly the same function as iov_from_buf() from
iov.c, so use the existing implementation and rename it
to qemu_iovec_from_buf() to be shorter and to match the
utility function.

As with utility implementation, we now assert that the
offset is inside actual iovec.  Nothing changed for
current callers, because `offset' parameter is new.

While at it, stop using "bounce-qiov" in block/qcow2.c
and copy decrypted data directly from cluster_data
instead of recreating a temp qiov for doing that.
Signed-off-by: NMichael Tokarev <mjt@tls.msk.ru>
      03396148
  43. 19 4月, 2012 1 次提交
  45. 03 4月, 2012 1 次提交
  47. 15 12月, 2011 1 次提交
  49. 21 9月, 2011 2 次提交
  51. 23 8月, 2011 1 次提交
    • N
      block/curl: Handle failed reads gracefully. · f785a5ae
      由 Nicholas Thomas 提交于 
      Current behaviour if a read fails is for the acb to not get finished.
This causes an infinite loop in bdrv_read_em (block.c). The read failure
never gets reported to the  guest and if the error condition clears, the
process never recovers.

With this patch, when curl reports a failure we finish the acb as a
failure. This results in the guest receiving an I/O error (rather than
the read hanging indefinitely) and if the error condition subsequently
clears, retries work as expected.

The simplest test is to put an ISO on a web server you have control over
and open it with qemu-io. Then move the ISO out of the way and attempt
to read some data - you should see behaviour matching the above.
Signed-off-by: NNick Thomas <nick@bytemark.co.uk>
Signed-off-by: NKevin Wolf <kwolf@redhat.com>
      f785a5ae
  53. 21 8月, 2011 1 次提交
  55. 22 5月, 2010 1 次提交
  57. 03 5月, 2010 1 次提交
    • K
      block: Open the underlying image file in generic code · 66f82cee
      由 Kevin Wolf 提交于 
      Format drivers shouldn't need to bother with things like file names, but rather
just get an open BlockDriverState for the underlying protocol. This patch
introduces this behaviour for bdrv_open implementation. For protocols which
need to access the filename to open their file/device/connection/... a new
callback bdrv_file_open is introduced which doesn't get an underlying file
opened.

For now, also some of the more obscure formats use bdrv_file_open because they
open() the file themselves instead of using the block.c functions. They need to
be fixed in later patches.
Signed-off-by: NKevin Wolf <kwolf@redhat.com>
      66f82cee
  59. 11 2月, 2010 1 次提交
    • J
      don't dereference NULL after failed strdup · 6265eb26
      由 Jim Meyering 提交于 
      Most of these are obvious NULL-deref bug fixes, for example,
the ones in these files:

  block/curl.c
  net.c
  slirp/misc.c

and the first one in block/vvfat.c.
The others in block/vvfat.c may not lead to an immediate segfault, but I
traced the two schedule_rename(..., strdup(path)) uses, and a failed
strdup would appear to trigger this assertion in handle_renames_and_mkdirs:

	    assert(commit->path);

The conversion to use qemu_strdup in envlist_to_environ is not technically
needed, but does avoid a theoretical leak in the caller when strdup fails
for one value, but later succeeds in allocating another buffer(plausible,
if one string length is much larger than the others).  The caller does
not know the length of the returned list, and as such can only free
pointers until it hits the first NULL.  If there are non-NULL pointers
beyond the first, their buffers would be leaked.  This one is admittedly
far-fetched.

The two in linux-user/main.c are worth fixing to ensure that an
OOM error is diagnosed up front, rather than letting it provoke some
harder-to-diagnose secondary error, in case of exec failure, or worse, in
case the exec succeeds but with an invalid list of command line options.
However, considering how unlikely it is to encounter a failed strdup early
in main, this isn't a big deal.  Note that adding the required uses of
qemu_strdup here and in envlist.c induce link failures because qemu_strdup
is not currently in any library they're linked with.  So for now, I've
omitted those changes, as well as the fixes in target-i386/helper.c
and target-sparc/helper.c.

If you'd like to see the above discussion (or anything else)
in the commit log, just let me know and I'll be happy to adjust.

>From 9af42864fd1ea666bd25e2cecfdfae74c20aa8c7 Mon Sep 17 00:00:00 2001
From: Jim Meyering <meyering@redhat.com>
Date: Mon, 8 Feb 2010 18:29:29 +0100
Subject: [PATCH] don't dereference NULL after failed strdup

Handle failing strdup by replacing each use with qemu_strdup,
so as not to dereference NULL or trigger a failing assertion.
* block/curl.c (curl_open): s/\bstrdup\b/qemu_strdup/
* block/vvfat.c (init_directories): Likewise.
(get_cluster_count_for_direntry, check_directory_consistency): Likewise.
* net.c (parse_host_src_port): Likewise.
* slirp/misc.c (fork_exec): Likewise.
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>
      6265eb26
  61. 08 2月, 2010 1 次提交
  63. 07 2月, 2010 1 次提交
  65. 28 10月, 2009 1 次提交
  67. 01 8月, 2009 1 次提交
  69. 10 7月, 2009 1 次提交
  71. 27 5月, 2009 1 次提交