[oe-commits] [openembedded-core] 19/59: recipes-devtools: Bump QEMU to 2.11.1
git at git.openembedded.org
git at git.openembedded.org
Sat Feb 24 10:36:38 UTC 2018
This is an automated email from the git hooks/post-receive script.
rpurdie pushed a commit to branch master
in repository openembedded-core.
commit da7fa8a15dfafd07e5956b69996d99880596c333
Author: Alistair Francis <alistair.francis at xilinx.com>
AuthorDate: Fri Feb 16 11:48:41 2018 -0800
recipes-devtools: Bump QEMU to 2.11.1
Bump the QEMU version to the bug fix release of 2.11.1 and remove the
patches that are no longer required.
Signed-off-by: Alistair Francis <alistair.francis at xilinx.com>
Signed-off-by: Ross Burton <ross.burton at intel.com>
---
.../qemu/qemu/CVE-2017-15124.patch | 1476 --------------------
.../qemu/{qemu_2.11.0.bb => qemu_2.11.1.bb} | 5 +-
2 files changed, 2 insertions(+), 1479 deletions(-)
diff --git a/meta/recipes-devtools/qemu/qemu/CVE-2017-15124.patch b/meta/recipes-devtools/qemu/qemu/CVE-2017-15124.patch
deleted file mode 100644
index a47b6d0..0000000
--- a/meta/recipes-devtools/qemu/qemu/CVE-2017-15124.patch
+++ /dev/null
@@ -1,1476 +0,0 @@
-VNC server implementation in Quick Emulator (QEMU) 2.11.0 and older was found to
-be vulnerable to an unbounded memory allocation issue, as it did not throttle
-the framebuffer updates sent to its client. If the client did not consume these
-updates, VNC server allocates growing memory to hold onto this data. A malicious
-remote VNC client could use this flaw to cause DoS to the server host.
-
-CVE: CVE-2017-15124
-Upstream-Status: Backport
-Signed-off-by: Ross Burton <ross.burton at intel.com>
-
-From 090fdc83b0960f68d204624a73c6814780da52d9 Mon Sep 17 00:00:00 2001
-From: =?UTF-8?q?Marc-Andr=C3=A9=20Lureau?= <marcandre.lureau at redhat.com>
-Date: Wed, 20 Dec 2017 15:06:18 +0100
-Subject: [PATCH 01/14] vnc: fix debug spelling
-MIME-Version: 1.0
-Content-Type: text/plain; charset=UTF-8
-Content-Transfer-Encoding: 8bit
-
-Signed-off-by: Marc-André Lureau <marcandre.lureau at redhat.com>
-Message-id: 20171220140618.12701-1-marcandre.lureau at redhat.com
-Signed-off-by: Gerd Hoffmann <kraxel at redhat.com>
----
- ui/vnc.c | 2 +-
- 1 file changed, 1 insertion(+), 1 deletion(-)
-
-diff --git a/ui/vnc.c b/ui/vnc.c
-index 9f8d5a1b1f..7d537b5c6b 100644
---- a/ui/vnc.c
-+++ b/ui/vnc.c
-@@ -2255,7 +2255,7 @@ static int protocol_client_msg(VncState *vs, uint8_t *data, size_t len)
- }
- vs->as.nchannels = read_u8(data, 5);
- if (vs->as.nchannels != 1 && vs->as.nchannels != 2) {
-- VNC_DEBUG("Invalid audio channel coount %d\n",
-+ VNC_DEBUG("Invalid audio channel count %d\n",
- read_u8(data, 5));
- vnc_client_error(vs);
- break;
---
-2.11.0
-
-
-From 6af998db05aec9af95a06f84ad94f1b96785e667 Mon Sep 17 00:00:00 2001
-From: "Daniel P. Berrange" <berrange at redhat.com>
-Date: Mon, 18 Dec 2017 19:12:16 +0000
-Subject: [PATCH 02/14] ui: remove 'sync' parameter from vnc_update_client
-MIME-Version: 1.0
-Content-Type: text/plain; charset=UTF-8
-Content-Transfer-Encoding: 8bit
-
-There is only one caller of vnc_update_client and that always passes false
-for the 'sync' parameter.
-
-Signed-off-by: Daniel P. Berrange <berrange at redhat.com>
-Reviewed-by: Darren Kenny <darren.kenny at oracle.com>
-Reviewed-by: Marc-André Lureau <marcandre.lureau at redhat.com>
-Message-id: 20171218191228.31018-2-berrange at redhat.com
-Signed-off-by: Gerd Hoffmann <kraxel at redhat.com>
----
- ui/vnc.c | 11 +++--------
- 1 file changed, 3 insertions(+), 8 deletions(-)
-
-diff --git a/ui/vnc.c b/ui/vnc.c
-index 7d537b5c6b..d72a61bde3 100644
---- a/ui/vnc.c
-+++ b/ui/vnc.c
-@@ -596,7 +596,7 @@ VncInfo2List *qmp_query_vnc_servers(Error **errp)
- 3) resolutions > 1024
- */
-
--static int vnc_update_client(VncState *vs, int has_dirty, bool sync);
-+static int vnc_update_client(VncState *vs, int has_dirty);
- static void vnc_disconnect_start(VncState *vs);
-
- static void vnc_colordepth(VncState *vs);
-@@ -961,7 +961,7 @@ static int find_and_clear_dirty_height(VncState *vs,
- return h;
- }
-
--static int vnc_update_client(VncState *vs, int has_dirty, bool sync)
-+static int vnc_update_client(VncState *vs, int has_dirty)
- {
- if (vs->disconnecting) {
- vnc_disconnect_finish(vs);
-@@ -1025,9 +1025,6 @@ static int vnc_update_client(VncState *vs, int has_dirty, bool sync)
- }
-
- vnc_job_push(job);
-- if (sync) {
-- vnc_jobs_join(vs);
-- }
- vs->force_update = 0;
- vs->has_dirty = 0;
- return n;
-@@ -1035,8 +1032,6 @@ static int vnc_update_client(VncState *vs, int has_dirty, bool sync)
-
- if (vs->disconnecting) {
- vnc_disconnect_finish(vs);
-- } else if (sync) {
-- vnc_jobs_join(vs);
- }
-
- return 0;
-@@ -2863,7 +2858,7 @@ static void vnc_refresh(DisplayChangeListener *dcl)
- vnc_unlock_display(vd);
-
- QTAILQ_FOREACH_SAFE(vs, &vd->clients, next, vn) {
-- rects += vnc_update_client(vs, has_dirty, false);
-+ rects += vnc_update_client(vs, has_dirty);
- /* vs might be free()ed here */
- }
-
---
-2.11.0
-
-
-From c53df961617736f94731d94b62c2954c261d2bae Mon Sep 17 00:00:00 2001
-From: "Daniel P. Berrange" <berrange at redhat.com>
-Date: Mon, 18 Dec 2017 19:12:17 +0000
-Subject: [PATCH 03/14] ui: remove unreachable code in vnc_update_client
-MIME-Version: 1.0
-Content-Type: text/plain; charset=UTF-8
-Content-Transfer-Encoding: 8bit
-
-A previous commit:
-
- commit 5a8be0f73d6f60ff08746377eb09ca459f39deab
- Author: Gerd Hoffmann <kraxel at redhat.com>
- Date: Wed Jul 13 12:21:20 2016 +0200
-
- vnc: make sure we finish disconnect
-
-Added a check for vs->disconnecting at the very start of the
-vnc_update_client method. This means that the very next "if"
-statement check for !vs->disconnecting always evaluates true,
-and is thus redundant. This in turn means the vs->disconnecting
-check at the very end of the method never evaluates true, and
-is thus unreachable code.
-
-Signed-off-by: Daniel P. Berrange <berrange at redhat.com>
-Reviewed-by: Darren Kenny <darren.kenny at oracle.com>
-Reviewed-by: Marc-André Lureau <marcandre.lureau at redhat.com>
-Message-id: 20171218191228.31018-3-berrange at redhat.com
-Signed-off-by: Gerd Hoffmann <kraxel at redhat.com>
----
- ui/vnc.c | 6 +-----
- 1 file changed, 1 insertion(+), 5 deletions(-)
-
-diff --git a/ui/vnc.c b/ui/vnc.c
-index d72a61bde3..29a7208475 100644
---- a/ui/vnc.c
-+++ b/ui/vnc.c
-@@ -969,7 +969,7 @@ static int vnc_update_client(VncState *vs, int has_dirty)
- }
-
- vs->has_dirty += has_dirty;
-- if (vs->need_update && !vs->disconnecting) {
-+ if (vs->need_update) {
- VncDisplay *vd = vs->vd;
- VncJob *job;
- int y;
-@@ -1030,10 +1030,6 @@ static int vnc_update_client(VncState *vs, int has_dirty)
- return n;
- }
-
-- if (vs->disconnecting) {
-- vnc_disconnect_finish(vs);
-- }
--
- return 0;
- }
-
---
-2.11.0
-
-
-From b939eb89b6f320544a9328fa908d881d0024c1ee Mon Sep 17 00:00:00 2001
-From: "Daniel P. Berrange" <berrange at redhat.com>
-Date: Mon, 18 Dec 2017 19:12:18 +0000
-Subject: [PATCH 04/14] ui: remove redundant indentation in vnc_client_update
-MIME-Version: 1.0
-Content-Type: text/plain; charset=UTF-8
-Content-Transfer-Encoding: 8bit
-
-Now that previous dead / unreachable code has been removed, we can simplify
-the indentation in the vnc_client_update method.
-
-Signed-off-by: Daniel P. Berrange <berrange at redhat.com>
-Reviewed-by: Darren Kenny <darren.kenny at oracle.com>
-Reviewed-by: Marc-André Lureau <marcandre.lureau at redhat.com>
-Message-id: 20171218191228.31018-4-berrange at redhat.com
-Signed-off-by: Gerd Hoffmann <kraxel at redhat.com>
----
- ui/vnc.c | 112 ++++++++++++++++++++++++++++++++-------------------------------
- 1 file changed, 57 insertions(+), 55 deletions(-)
-
-diff --git a/ui/vnc.c b/ui/vnc.c
-index 29a7208475..7582111ca6 100644
---- a/ui/vnc.c
-+++ b/ui/vnc.c
-@@ -963,74 +963,76 @@ static int find_and_clear_dirty_height(VncState *vs,
-
- static int vnc_update_client(VncState *vs, int has_dirty)
- {
-+ VncDisplay *vd = vs->vd;
-+ VncJob *job;
-+ int y;
-+ int height, width;
-+ int n = 0;
-+
- if (vs->disconnecting) {
- vnc_disconnect_finish(vs);
- return 0;
- }
-
- vs->has_dirty += has_dirty;
-- if (vs->need_update) {
-- VncDisplay *vd = vs->vd;
-- VncJob *job;
-- int y;
-- int height, width;
-- int n = 0;
--
-- if (vs->output.offset && !vs->audio_cap && !vs->force_update)
-- /* kernel send buffers are full -> drop frames to throttle */
-- return 0;
-+ if (!vs->need_update) {
-+ return 0;
-+ }
-
-- if (!vs->has_dirty && !vs->audio_cap && !vs->force_update)
-- return 0;
-+ if (vs->output.offset && !vs->audio_cap && !vs->force_update) {
-+ /* kernel send buffers are full -> drop frames to throttle */
-+ return 0;
-+ }
-
-- /*
-- * Send screen updates to the vnc client using the server
-- * surface and server dirty map. guest surface updates
-- * happening in parallel don't disturb us, the next pass will
-- * send them to the client.
-- */
-- job = vnc_job_new(vs);
--
-- height = pixman_image_get_height(vd->server);
-- width = pixman_image_get_width(vd->server);
--
-- y = 0;
-- for (;;) {
-- int x, h;
-- unsigned long x2;
-- unsigned long offset = find_next_bit((unsigned long *) &vs->dirty,
-- height * VNC_DIRTY_BPL(vs),
-- y * VNC_DIRTY_BPL(vs));
-- if (offset == height * VNC_DIRTY_BPL(vs)) {
-- /* no more dirty bits */
-+ if (!vs->has_dirty && !vs->audio_cap && !vs->force_update) {
-+ return 0;
-+ }
-+
-+ /*
-+ * Send screen updates to the vnc client using the server
-+ * surface and server dirty map. guest surface updates
-+ * happening in parallel don't disturb us, the next pass will
-+ * send them to the client.
-+ */
-+ job = vnc_job_new(vs);
-+
-+ height = pixman_image_get_height(vd->server);
-+ width = pixman_image_get_width(vd->server);
-+
-+ y = 0;
-+ for (;;) {
-+ int x, h;
-+ unsigned long x2;
-+ unsigned long offset = find_next_bit((unsigned long *) &vs->dirty,
-+ height * VNC_DIRTY_BPL(vs),
-+ y * VNC_DIRTY_BPL(vs));
-+ if (offset == height * VNC_DIRTY_BPL(vs)) {
-+ /* no more dirty bits */
-+ break;
-+ }
-+ y = offset / VNC_DIRTY_BPL(vs);
-+ x = offset % VNC_DIRTY_BPL(vs);
-+ x2 = find_next_zero_bit((unsigned long *) &vs->dirty[y],
-+ VNC_DIRTY_BPL(vs), x);
-+ bitmap_clear(vs->dirty[y], x, x2 - x);
-+ h = find_and_clear_dirty_height(vs, y, x, x2, height);
-+ x2 = MIN(x2, width / VNC_DIRTY_PIXELS_PER_BIT);
-+ if (x2 > x) {
-+ n += vnc_job_add_rect(job, x * VNC_DIRTY_PIXELS_PER_BIT, y,
-+ (x2 - x) * VNC_DIRTY_PIXELS_PER_BIT, h);
-+ }
-+ if (!x && x2 == width / VNC_DIRTY_PIXELS_PER_BIT) {
-+ y += h;
-+ if (y == height) {
- break;
- }
-- y = offset / VNC_DIRTY_BPL(vs);
-- x = offset % VNC_DIRTY_BPL(vs);
-- x2 = find_next_zero_bit((unsigned long *) &vs->dirty[y],
-- VNC_DIRTY_BPL(vs), x);
-- bitmap_clear(vs->dirty[y], x, x2 - x);
-- h = find_and_clear_dirty_height(vs, y, x, x2, height);
-- x2 = MIN(x2, width / VNC_DIRTY_PIXELS_PER_BIT);
-- if (x2 > x) {
-- n += vnc_job_add_rect(job, x * VNC_DIRTY_PIXELS_PER_BIT, y,
-- (x2 - x) * VNC_DIRTY_PIXELS_PER_BIT, h);
-- }
-- if (!x && x2 == width / VNC_DIRTY_PIXELS_PER_BIT) {
-- y += h;
-- if (y == height) {
-- break;
-- }
-- }
- }
--
-- vnc_job_push(job);
-- vs->force_update = 0;
-- vs->has_dirty = 0;
-- return n;
- }
-
-- return 0;
-+ vnc_job_push(job);
-+ vs->force_update = 0;
-+ vs->has_dirty = 0;
-+ return n;
- }
-
- /* audio */
---
-2.11.0
-
-
-From 3541b08475d51bddf8aded36576a0ff5a547a978 Mon Sep 17 00:00:00 2001
-From: "Daniel P. Berrange" <berrange at redhat.com>
-Date: Mon, 18 Dec 2017 19:12:19 +0000
-Subject: [PATCH 05/14] ui: avoid pointless VNC updates if framebuffer isn't
- dirty
-MIME-Version: 1.0
-Content-Type: text/plain; charset=UTF-8
-Content-Transfer-Encoding: 8bit
-
-The vnc_update_client() method checks the 'has_dirty' flag to see if there are
-dirty regions that are pending to send to the client. Regardless of this flag,
-if a forced update is requested, updates must be sent. For unknown reasons
-though, the code also tries to sent updates if audio capture is enabled. This
-makes no sense as audio capture state does not impact framebuffer contents, so
-this check is removed.
-
-Signed-off-by: Daniel P. Berrange <berrange at redhat.com>
-Reviewed-by: Darren Kenny <darren.kenny at oracle.com>
-Reviewed-by: Marc-André Lureau <marcandre.lureau at redhat.com>
-Message-id: 20171218191228.31018-5-berrange at redhat.com
-Signed-off-by: Gerd Hoffmann <kraxel at redhat.com>
----
- ui/vnc.c | 2 +-
- 1 file changed, 1 insertion(+), 1 deletion(-)
-
-diff --git a/ui/vnc.c b/ui/vnc.c
-index 7582111ca6..a79848f083 100644
---- a/ui/vnc.c
-+++ b/ui/vnc.c
-@@ -984,7 +984,7 @@ static int vnc_update_client(VncState *vs, int has_dirty)
- return 0;
- }
-
-- if (!vs->has_dirty && !vs->audio_cap && !vs->force_update) {
-+ if (!vs->has_dirty && !vs->force_update) {
- return 0;
- }
-
---
-2.11.0
-
-
-From 8f61f1c5a6bc06438a1172efa80bc7606594fa07 Mon Sep 17 00:00:00 2001
-From: "Daniel P. Berrange" <berrange at redhat.com>
-Date: Mon, 18 Dec 2017 19:12:20 +0000
-Subject: [PATCH 06/14] ui: track how much decoded data we consumed when doing
- SASL encoding
-MIME-Version: 1.0
-Content-Type: text/plain; charset=UTF-8
-Content-Transfer-Encoding: 8bit
-
-When we encode data for writing with SASL, we encode the entire pending output
-buffer. The subsequent write, however, may not be able to send the full encoded
-data in one go though, particularly with a slow network. So we delay setting the
-output buffer offset back to zero until all the SASL encoded data is sent.
-
-Between encoding the data and completing sending of the SASL encoded data,
-however, more data might have been placed on the pending output buffer. So it
-is not valid to set offset back to zero. Instead we must keep track of how much
-data we consumed during encoding and subtract only that amount.
-
-With the current bug we would be throwing away some pending data without having
-sent it at all. By sheer luck this did not previously cause any serious problem
-because appending data to the send buffer is always an atomic action, so we
-only ever throw away complete RFB protocol messages. In the case of frame buffer
-updates we'd catch up fairly quickly, so no obvious problem was visible.
-
-Signed-off-by: Daniel P. Berrange <berrange at redhat.com>
-Reviewed-by: Darren Kenny <darren.kenny at oracle.com>
-Reviewed-by: Marc-André Lureau <marcandre.lureau at redhat.com>
-Message-id: 20171218191228.31018-6-berrange at redhat.com
-Signed-off-by: Gerd Hoffmann <kraxel at redhat.com>
----
- ui/vnc-auth-sasl.c | 3 ++-
- ui/vnc-auth-sasl.h | 1 +
- 2 files changed, 3 insertions(+), 1 deletion(-)
-
-diff --git a/ui/vnc-auth-sasl.c b/ui/vnc-auth-sasl.c
-index 23f28280e7..761493b9b2 100644
---- a/ui/vnc-auth-sasl.c
-+++ b/ui/vnc-auth-sasl.c
-@@ -67,6 +67,7 @@ long vnc_client_write_sasl(VncState *vs)
- if (err != SASL_OK)
- return vnc_client_io_error(vs, -1, NULL);
-
-+ vs->sasl.encodedRawLength = vs->output.offset;
- vs->sasl.encodedOffset = 0;
- }
-
-@@ -78,7 +79,7 @@ long vnc_client_write_sasl(VncState *vs)
-
- vs->sasl.encodedOffset += ret;
- if (vs->sasl.encodedOffset == vs->sasl.encodedLength) {
-- vs->output.offset = 0;
-+ vs->output.offset -= vs->sasl.encodedRawLength;
- vs->sasl.encoded = NULL;
- vs->sasl.encodedOffset = vs->sasl.encodedLength = 0;
- }
-diff --git a/ui/vnc-auth-sasl.h b/ui/vnc-auth-sasl.h
-index cb42745a6b..b9d8de1c10 100644
---- a/ui/vnc-auth-sasl.h
-+++ b/ui/vnc-auth-sasl.h
-@@ -53,6 +53,7 @@ struct VncStateSASL {
- */
- const uint8_t *encoded;
- unsigned int encodedLength;
-+ unsigned int encodedRawLength;
- unsigned int encodedOffset;
- char *username;
- char *mechlist;
---
-2.11.0
-
-
-From fef1bbadfb2c3027208eb3d14b43e1bdb51166ca Mon Sep 17 00:00:00 2001
-From: "Daniel P. Berrange" <berrange at redhat.com>
-Date: Mon, 18 Dec 2017 19:12:21 +0000
-Subject: [PATCH 07/14] ui: introduce enum to track VNC client framebuffer
- update request state
-MIME-Version: 1.0
-Content-Type: text/plain; charset=UTF-8
-Content-Transfer-Encoding: 8bit
-
-Currently the VNC servers tracks whether a client has requested an incremental
-or forced update with two boolean flags. There are only really 3 distinct
-states to track, so create an enum to more accurately reflect permitted states.
-
-Signed-off-by: Daniel P. Berrange <berrange at redhat.com>
-Reviewed-by: Darren Kenny <darren.kenny at oracle.com>
-Reviewed-by: Marc-André Lureau <marcandre.lureau at redhat.com>
-Message-id: 20171218191228.31018-7-berrange at redhat.com
-Signed-off-by: Gerd Hoffmann <kraxel at redhat.com>
----
- ui/vnc.c | 21 +++++++++++----------
- ui/vnc.h | 9 +++++++--
- 2 files changed, 18 insertions(+), 12 deletions(-)
-
-diff --git a/ui/vnc.c b/ui/vnc.c
-index a79848f083..30e2feeae3 100644
---- a/ui/vnc.c
-+++ b/ui/vnc.c
-@@ -975,16 +975,17 @@ static int vnc_update_client(VncState *vs, int has_dirty)
- }
-
- vs->has_dirty += has_dirty;
-- if (!vs->need_update) {
-+ if (vs->update == VNC_STATE_UPDATE_NONE) {
- return 0;
- }
-
-- if (vs->output.offset && !vs->audio_cap && !vs->force_update) {
-+ if (vs->output.offset && !vs->audio_cap &&
-+ vs->update != VNC_STATE_UPDATE_FORCE) {
- /* kernel send buffers are full -> drop frames to throttle */
- return 0;
- }
-
-- if (!vs->has_dirty && !vs->force_update) {
-+ if (!vs->has_dirty && vs->update != VNC_STATE_UPDATE_FORCE) {
- return 0;
- }
-
-@@ -1030,7 +1031,7 @@ static int vnc_update_client(VncState *vs, int has_dirty)
- }
-
- vnc_job_push(job);
-- vs->force_update = 0;
-+ vs->update = VNC_STATE_UPDATE_INCREMENTAL;
- vs->has_dirty = 0;
- return n;
- }
-@@ -1869,14 +1870,14 @@ static void ext_key_event(VncState *vs, int down,
- static void framebuffer_update_request(VncState *vs, int incremental,
- int x, int y, int w, int h)
- {
-- vs->need_update = 1;
--
- if (incremental) {
-- return;
-+ if (vs->update != VNC_STATE_UPDATE_FORCE) {
-+ vs->update = VNC_STATE_UPDATE_INCREMENTAL;
-+ }
-+ } else {
-+ vs->update = VNC_STATE_UPDATE_FORCE;
-+ vnc_set_area_dirty(vs->dirty, vs->vd, x, y, w, h);
- }
--
-- vs->force_update = 1;
-- vnc_set_area_dirty(vs->dirty, vs->vd, x, y, w, h);
- }
-
- static void send_ext_key_event_ack(VncState *vs)
-diff --git a/ui/vnc.h b/ui/vnc.h
-index 694cf32ca9..b9d310e640 100644
---- a/ui/vnc.h
-+++ b/ui/vnc.h
-@@ -252,6 +252,12 @@ struct VncJob
- QTAILQ_ENTRY(VncJob) next;
- };
-
-+typedef enum {
-+ VNC_STATE_UPDATE_NONE,
-+ VNC_STATE_UPDATE_INCREMENTAL,
-+ VNC_STATE_UPDATE_FORCE,
-+} VncStateUpdate;
-+
- struct VncState
- {
- QIOChannelSocket *sioc; /* The underlying socket */
-@@ -264,8 +270,7 @@ struct VncState
- * vnc-jobs-async.c */
-
- VncDisplay *vd;
-- int need_update;
-- int force_update;
-+ VncStateUpdate update; /* Most recent pending request from client */
- int has_dirty;
- uint32_t features;
- int absolute;
---
-2.11.0
-
-
-From 728a7ac95484a7ba5e624ccbac4c1326571576b0 Mon Sep 17 00:00:00 2001
-From: "Daniel P. Berrange" <berrange at redhat.com>
-Date: Mon, 18 Dec 2017 19:12:22 +0000
-Subject: [PATCH 08/14] ui: correctly reset framebuffer update state after
- processing dirty regions
-MIME-Version: 1.0
-Content-Type: text/plain; charset=UTF-8
-Content-Transfer-Encoding: 8bit
-
-According to the RFB protocol, a client sends one or more framebuffer update
-requests to the server. The server can reply with a single framebuffer update
-response, that covers all previously received requests. Once the client has
-read this update from the server, it may send further framebuffer update
-requests to monitor future changes. The client is free to delay sending the
-framebuffer update request if it needs to throttle the amount of data it is
-reading from the server.
-
-The QEMU VNC server, however, has never correctly handled the framebuffer
-update requests. Once QEMU has received an update request, it will continue to
-send client updates forever, even if the client hasn't asked for further
-updates. This prevents the client from throttling back data it gets from the
-server. This change fixes the flawed logic such that after a set of updates are
-sent out, QEMU waits for a further update request before sending more data.
-
-Signed-off-by: Daniel P. Berrange <berrange at redhat.com>
-Reviewed-by: Darren Kenny <darren.kenny at oracle.com>
-Reviewed-by: Marc-André Lureau <marcandre.lureau at redhat.com>
-Message-id: 20171218191228.31018-8-berrange at redhat.com
-Signed-off-by: Gerd Hoffmann <kraxel at redhat.com>
----
- ui/vnc.c | 2 +-
- 1 file changed, 1 insertion(+), 1 deletion(-)
-
-diff --git a/ui/vnc.c b/ui/vnc.c
-index 30e2feeae3..243c72be13 100644
---- a/ui/vnc.c
-+++ b/ui/vnc.c
-@@ -1031,7 +1031,7 @@ static int vnc_update_client(VncState *vs, int has_dirty)
- }
-
- vnc_job_push(job);
-- vs->update = VNC_STATE_UPDATE_INCREMENTAL;
-+ vs->update = VNC_STATE_UPDATE_NONE;
- vs->has_dirty = 0;
- return n;
- }
---
-2.11.0
-
-
-From 0bad834228b9ee63e4239108d02dcb94568254d0 Mon Sep 17 00:00:00 2001
-From: "Daniel P. Berrange" <berrange at redhat.com>
-Date: Mon, 18 Dec 2017 19:12:23 +0000
-Subject: [PATCH 09/14] ui: refactor code for determining if an update should
- be sent to the client
-MIME-Version: 1.0
-Content-Type: text/plain; charset=UTF-8
-Content-Transfer-Encoding: 8bit
-
-The logic for determining if it is possible to send an update to the client
-will become more complicated shortly, so pull it out into a separate method
-for easier extension later.
-
-Signed-off-by: Daniel P. Berrange <berrange at redhat.com>
-Reviewed-by: Darren Kenny <darren.kenny at oracle.com>
-Reviewed-by: Marc-André Lureau <marcandre.lureau at redhat.com>
-Message-id: 20171218191228.31018-9-berrange at redhat.com
-Signed-off-by: Gerd Hoffmann <kraxel at redhat.com>
----
- ui/vnc.c | 27 ++++++++++++++++++++-------
- 1 file changed, 20 insertions(+), 7 deletions(-)
-
-diff --git a/ui/vnc.c b/ui/vnc.c
-index 243c72be13..4ba7fc076a 100644
---- a/ui/vnc.c
-+++ b/ui/vnc.c
-@@ -961,6 +961,25 @@ static int find_and_clear_dirty_height(VncState *vs,
- return h;
- }
-
-+static bool vnc_should_update(VncState *vs)
-+{
-+ switch (vs->update) {
-+ case VNC_STATE_UPDATE_NONE:
-+ break;
-+ case VNC_STATE_UPDATE_INCREMENTAL:
-+ /* Only allow incremental updates if the output buffer
-+ * is empty, or if audio capture is enabled.
-+ */
-+ if (!vs->output.offset || vs->audio_cap) {
-+ return true;
-+ }
-+ break;
-+ case VNC_STATE_UPDATE_FORCE:
-+ return true;
-+ }
-+ return false;
-+}
-+
- static int vnc_update_client(VncState *vs, int has_dirty)
- {
- VncDisplay *vd = vs->vd;
-@@ -975,13 +994,7 @@ static int vnc_update_client(VncState *vs, int has_dirty)
- }
-
- vs->has_dirty += has_dirty;
-- if (vs->update == VNC_STATE_UPDATE_NONE) {
-- return 0;
-- }
--
-- if (vs->output.offset && !vs->audio_cap &&
-- vs->update != VNC_STATE_UPDATE_FORCE) {
-- /* kernel send buffers are full -> drop frames to throttle */
-+ if (!vnc_should_update(vs)) {
- return 0;
- }
-
---
-2.11.0
-
-
-From e2b72cb6e0443d90d7ab037858cb6834b6cca852 Mon Sep 17 00:00:00 2001
-From: "Daniel P. Berrange" <berrange at redhat.com>
-Date: Mon, 18 Dec 2017 19:12:24 +0000
-Subject: [PATCH 10/14] ui: fix VNC client throttling when audio capture is
- active
-MIME-Version: 1.0
-Content-Type: text/plain; charset=UTF-8
-Content-Transfer-Encoding: 8bit
-
-The VNC server must throttle data sent to the client to prevent the 'output'
-buffer size growing without bound, if the client stops reading data off the
-socket (either maliciously or due to stalled/slow network connection).
-
-The current throttling is very crude because it simply checks whether the
-output buffer offset is zero. This check must be disabled if audio capture is
-enabled, because when streaming audio the output buffer offset will rarely be
-zero due to queued audio data, and so this would starve framebuffer updates.
-
-As a result, the VNC client can cause QEMU to allocate arbitrary amounts of RAM.
-They can first start something in the guest that triggers lots of framebuffer
-updates eg play a youtube video. Then enable audio capture, and simply never
-read data back from the server. This can easily make QEMU's VNC server send
-buffer consume 100MB of RAM per second, until the OOM killer starts reaping
-processes (hopefully the rogue QEMU process, but it might pick others...).
-
-To address this we make the throttling more intelligent, so we can throttle
-when audio capture is active too. To determine how to throttle incremental
-updates or audio data, we calculate a size threshold. Normally the threshold is
-the approximate number of bytes associated with a single complete framebuffer
-update. ie width * height * bytes per pixel. We'll send incremental updates
-until we hit this threshold, at which point we'll stop sending updates until
-data has been written to the wire, causing the output buffer offset to fall
-back below the threshold.
-
-If audio capture is enabled, we increase the size of the threshold to also
-allow for upto 1 seconds worth of audio data samples. ie nchannels * bytes
-per sample * frequency. This allows the output buffer to have a mixture of
-incremental framebuffer updates and audio data queued, but once the threshold
-is exceeded, audio data will be dropped and incremental updates will be
-throttled.
-
-This unbounded memory growth affects all VNC server configurations supported by
-QEMU, with no workaround possible. The mitigating factor is that it can only be
-triggered by a client that has authenticated with the VNC server, and who is
-able to trigger a large quantity of framebuffer updates or audio samples from
-the guest OS. Mostly they'll just succeed in getting the OOM killer to kill
-their own QEMU process, but its possible other processes can get taken out as
-collateral damage.
-
-This is a more general variant of the similar unbounded memory usage flaw in
-the websockets server, that was previously assigned CVE-2017-15268, and fixed
-in 2.11 by:
-
- commit a7b20a8efa28e5f22c26c06cd06c2f12bc863493
- Author: Daniel P. Berrange <berrange at redhat.com>
- Date: Mon Oct 9 14:43:42 2017 +0100
-
- io: monitor encoutput buffer size from websocket GSource
-
-This new general memory usage flaw has been assigned CVE-2017-15124, and is
-partially fixed by this patch.
-
-Signed-off-by: Daniel P. Berrange <berrange at redhat.com>
-Reviewed-by: Darren Kenny <darren.kenny at oracle.com>
-Reviewed-by: Marc-André Lureau <marcandre.lureau at redhat.com>
-Message-id: 20171218191228.31018-10-berrange at redhat.com
-Signed-off-by: Gerd Hoffmann <kraxel at redhat.com>
----
- ui/vnc.c | 72 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++--------
- ui/vnc.h | 6 ++++++
- 2 files changed, 70 insertions(+), 8 deletions(-)
-
-diff --git a/ui/vnc.c b/ui/vnc.c
-index 4ba7fc076a..9e03cc7c01 100644
---- a/ui/vnc.c
-+++ b/ui/vnc.c
-@@ -60,6 +60,7 @@ static QTAILQ_HEAD(, VncDisplay) vnc_displays =
-
- static int vnc_cursor_define(VncState *vs);
- static void vnc_release_modifiers(VncState *vs);
-+static void vnc_update_throttle_offset(VncState *vs);
-
- static void vnc_set_share_mode(VncState *vs, VncShareMode mode)
- {
-@@ -766,6 +767,7 @@ static void vnc_dpy_switch(DisplayChangeListener *dcl,
- vnc_set_area_dirty(vs->dirty, vd, 0, 0,
- vnc_width(vd),
- vnc_height(vd));
-+ vnc_update_throttle_offset(vs);
- }
- }
-
-@@ -961,16 +963,67 @@ static int find_and_clear_dirty_height(VncState *vs,
- return h;
- }
-
-+/*
-+ * Figure out how much pending data we should allow in the output
-+ * buffer before we throttle incremental display updates, and/or
-+ * drop audio samples.
-+ *
-+ * We allow for equiv of 1 full display's worth of FB updates,
-+ * and 1 second of audio samples. If audio backlog was larger
-+ * than that the client would already suffering awful audio
-+ * glitches, so dropping samples is no worse really).
-+ */
-+static void vnc_update_throttle_offset(VncState *vs)
-+{
-+ size_t offset =
-+ vs->client_width * vs->client_height * vs->client_pf.bytes_per_pixel;
-+
-+ if (vs->audio_cap) {
-+ int freq = vs->as.freq;
-+ /* We don't limit freq when reading settings from client, so
-+ * it could be upto MAX_INT in size. 48khz is a sensible
-+ * upper bound for trustworthy clients */
-+ int bps;
-+ if (freq > 48000) {
-+ freq = 48000;
-+ }
-+ switch (vs->as.fmt) {
-+ default:
-+ case AUD_FMT_U8:
-+ case AUD_FMT_S8:
-+ bps = 1;
-+ break;
-+ case AUD_FMT_U16:
-+ case AUD_FMT_S16:
-+ bps = 2;
-+ break;
-+ case AUD_FMT_U32:
-+ case AUD_FMT_S32:
-+ bps = 4;
-+ break;
-+ }
-+ offset += freq * bps * vs->as.nchannels;
-+ }
-+
-+ /* Put a floor of 1MB on offset, so that if we have a large pending
-+ * buffer and the display is resized to a small size & back again
-+ * we don't suddenly apply a tiny send limit
-+ */
-+ offset = MAX(offset, 1024 * 1024);
-+
-+ vs->throttle_output_offset = offset;
-+}
-+
- static bool vnc_should_update(VncState *vs)
- {
- switch (vs->update) {
- case VNC_STATE_UPDATE_NONE:
- break;
- case VNC_STATE_UPDATE_INCREMENTAL:
-- /* Only allow incremental updates if the output buffer
-- * is empty, or if audio capture is enabled.
-+ /* Only allow incremental updates if the pending send queue
-+ * is less than the permitted threshold
- */
-- if (!vs->output.offset || vs->audio_cap) {
-+ if (vs->output.offset < vs->throttle_output_offset) {
- return true;
- }
- break;
-@@ -1084,11 +1137,13 @@ static void audio_capture(void *opaque, void *buf, int size)
- VncState *vs = opaque;
-
- vnc_lock_output(vs);
-- vnc_write_u8(vs, VNC_MSG_SERVER_QEMU);
-- vnc_write_u8(vs, VNC_MSG_SERVER_QEMU_AUDIO);
-- vnc_write_u16(vs, VNC_MSG_SERVER_QEMU_AUDIO_DATA);
-- vnc_write_u32(vs, size);
-- vnc_write(vs, buf, size);
-+ if (vs->output.offset < vs->throttle_output_offset) {
-+ vnc_write_u8(vs, VNC_MSG_SERVER_QEMU);
-+ vnc_write_u8(vs, VNC_MSG_SERVER_QEMU_AUDIO);
-+ vnc_write_u16(vs, VNC_MSG_SERVER_QEMU_AUDIO_DATA);
-+ vnc_write_u32(vs, size);
-+ vnc_write(vs, buf, size);
-+ }
- vnc_unlock_output(vs);
- vnc_flush(vs);
- }
-@@ -2288,6 +2343,7 @@ static int protocol_client_msg(VncState *vs, uint8_t *data, size_t len)
- break;
- }
-
-+ vnc_update_throttle_offset(vs);
- vnc_read_when(vs, protocol_client_msg, 1);
- return 0;
- }
-diff --git a/ui/vnc.h b/ui/vnc.h
-index b9d310e640..8fe69595c6 100644
---- a/ui/vnc.h
-+++ b/ui/vnc.h
-@@ -298,6 +298,12 @@ struct VncState
-
- VncClientInfo *info;
-
-+ /* We allow multiple incremental updates or audio capture
-+ * samples to be queued in output buffer, provided the
-+ * buffer size doesn't exceed this threshold. The value
-+ * is calculating dynamically based on framebuffer size
-+ * and audio sample settings in vnc_update_throttle_offset() */
-+ size_t throttle_output_offset;
- Buffer output;
- Buffer input;
- /* current output mode information */
---
-2.11.0
-
-
-From ada8d2e4369ea49677d8672ac81bce73eefd5b54 Mon Sep 17 00:00:00 2001
-From: "Daniel P. Berrange" <berrange at redhat.com>
-Date: Mon, 18 Dec 2017 19:12:25 +0000
-Subject: [PATCH 11/14] ui: fix VNC client throttling when forced update is
- requested
-MIME-Version: 1.0
-Content-Type: text/plain; charset=UTF-8
-Content-Transfer-Encoding: 8bit
-
-The VNC server must throttle data sent to the client to prevent the 'output'
-buffer size growing without bound, if the client stops reading data off the
-socket (either maliciously or due to stalled/slow network connection).
-
-The current throttling is very crude because it simply checks whether the
-output buffer offset is zero. This check is disabled if the client has requested
-a forced update, because we want to send these as soon as possible.
-
-As a result, the VNC client can cause QEMU to allocate arbitrary amounts of RAM.
-They can first start something in the guest that triggers lots of framebuffer
-updates eg play a youtube video. Then repeatedly send full framebuffer update
-requests, but never read data back from the server. This can easily make QEMU's
-VNC server send buffer consume 100MB of RAM per second, until the OOM killer
-starts reaping processes (hopefully the rogue QEMU process, but it might pick
-others...).
-
-To address this we make the throttling more intelligent, so we can throttle
-full updates. When we get a forced update request, we keep track of exactly how
-much data we put on the output buffer. We will not process a subsequent forced
-update request until this data has been fully sent on the wire. We always allow
-one forced update request to be in flight, regardless of what data is queued
-for incremental updates or audio data. The slight complication is that we do
-not initially know how much data an update will send, as this is done in the
-background by the VNC job thread. So we must track the fact that the job thread
-has an update pending, and not process any further updates until this job is
-has been completed & put data on the output buffer.
-
-This unbounded memory growth affects all VNC server configurations supported by
-QEMU, with no workaround possible. The mitigating factor is that it can only be
-triggered by a client that has authenticated with the VNC server, and who is
-able to trigger a large quantity of framebuffer updates or audio samples from
-the guest OS. Mostly they'll just succeed in getting the OOM killer to kill
-their own QEMU process, but its possible other processes can get taken out as
-collateral damage.
-
-This is a more general variant of the similar unbounded memory usage flaw in
-the websockets server, that was previously assigned CVE-2017-15268, and fixed
-in 2.11 by:
-
- commit a7b20a8efa28e5f22c26c06cd06c2f12bc863493
- Author: Daniel P. Berrange <berrange at redhat.com>
- Date: Mon Oct 9 14:43:42 2017 +0100
-
- io: monitor encoutput buffer size from websocket GSource
-
-This new general memory usage flaw has been assigned CVE-2017-15124, and is
-partially fixed by this patch.
-
-Signed-off-by: Daniel P. Berrange <berrange at redhat.com>
-Reviewed-by: Darren Kenny <darren.kenny at oracle.com>
-Reviewed-by: Marc-André Lureau <marcandre.lureau at redhat.com>
-Message-id: 20171218191228.31018-11-berrange at redhat.com
-Signed-off-by: Gerd Hoffmann <kraxel at redhat.com>
----
- ui/vnc-auth-sasl.c | 5 +++++
- ui/vnc-jobs.c | 5 +++++
- ui/vnc.c | 28 ++++++++++++++++++++++++----
- ui/vnc.h | 7 +++++++
- 4 files changed, 41 insertions(+), 4 deletions(-)
-
-diff --git a/ui/vnc-auth-sasl.c b/ui/vnc-auth-sasl.c
-index 761493b9b2..8c1cdde3db 100644
---- a/ui/vnc-auth-sasl.c
-+++ b/ui/vnc-auth-sasl.c
-@@ -79,6 +79,11 @@ long vnc_client_write_sasl(VncState *vs)
-
- vs->sasl.encodedOffset += ret;
- if (vs->sasl.encodedOffset == vs->sasl.encodedLength) {
-+ if (vs->sasl.encodedRawLength >= vs->force_update_offset) {
-+ vs->force_update_offset = 0;
-+ } else {
-+ vs->force_update_offset -= vs->sasl.encodedRawLength;
-+ }
- vs->output.offset -= vs->sasl.encodedRawLength;
- vs->sasl.encoded = NULL;
- vs->sasl.encodedOffset = vs->sasl.encodedLength = 0;
-diff --git a/ui/vnc-jobs.c b/ui/vnc-jobs.c
-index f7867771ae..e326679dd0 100644
---- a/ui/vnc-jobs.c
-+++ b/ui/vnc-jobs.c
-@@ -152,6 +152,11 @@ void vnc_jobs_consume_buffer(VncState *vs)
- vs->ioc, G_IO_IN | G_IO_OUT, vnc_client_io, vs, NULL);
- }
- buffer_move(&vs->output, &vs->jobs_buffer);
-+
-+ if (vs->job_update == VNC_STATE_UPDATE_FORCE) {
-+ vs->force_update_offset = vs->output.offset;
-+ }
-+ vs->job_update = VNC_STATE_UPDATE_NONE;
- }
- flush = vs->ioc != NULL && vs->abort != true;
- vnc_unlock_output(vs);
-diff --git a/ui/vnc.c b/ui/vnc.c
-index 9e03cc7c01..4805ac41d0 100644
---- a/ui/vnc.c
-+++ b/ui/vnc.c
-@@ -1021,14 +1021,28 @@ static bool vnc_should_update(VncState *vs)
- break;
- case VNC_STATE_UPDATE_INCREMENTAL:
- /* Only allow incremental updates if the pending send queue
-- * is less than the permitted threshold
-+ * is less than the permitted threshold, and the job worker
-+ * is completely idle.
- */
-- if (vs->output.offset < vs->throttle_output_offset) {
-+ if (vs->output.offset < vs->throttle_output_offset &&
-+ vs->job_update == VNC_STATE_UPDATE_NONE) {
- return true;
- }
- break;
- case VNC_STATE_UPDATE_FORCE:
-- return true;
-+ /* Only allow forced updates if the pending send queue
-+ * does not contain a previous forced update, and the
-+ * job worker is completely idle.
-+ *
-+ * Note this means we'll queue a forced update, even if
-+ * the output buffer size is otherwise over the throttle
-+ * output limit.
-+ */
-+ if (vs->force_update_offset == 0 &&
-+ vs->job_update == VNC_STATE_UPDATE_NONE) {
-+ return true;
-+ }
-+ break;
- }
- return false;
- }
-@@ -1096,8 +1110,9 @@ static int vnc_update_client(VncState *vs, int has_dirty)
- }
- }
-
-- vnc_job_push(job);
-+ vs->job_update = vs->update;
- vs->update = VNC_STATE_UPDATE_NONE;
-+ vnc_job_push(job);
- vs->has_dirty = 0;
- return n;
- }
-@@ -1332,6 +1347,11 @@ static ssize_t vnc_client_write_plain(VncState *vs)
- if (!ret)
- return 0;
-
-+ if (ret >= vs->force_update_offset) {
-+ vs->force_update_offset = 0;
-+ } else {
-+ vs->force_update_offset -= ret;
-+ }
- buffer_advance(&vs->output, ret);
-
- if (vs->output.offset == 0) {
-diff --git a/ui/vnc.h b/ui/vnc.h
-index 8fe69595c6..3f4cd4d93d 100644
---- a/ui/vnc.h
-+++ b/ui/vnc.h
-@@ -271,6 +271,7 @@ struct VncState
-
- VncDisplay *vd;
- VncStateUpdate update; /* Most recent pending request from client */
-+ VncStateUpdate job_update; /* Currently processed by job thread */
- int has_dirty;
- uint32_t features;
- int absolute;
-@@ -298,6 +299,12 @@ struct VncState
-
- VncClientInfo *info;
-
-+ /* Job thread bottom half has put data for a forced update
-+ * into the output buffer. This offset points to the end of
-+ * the update data in the output buffer. This lets us determine
-+ * when a force update is fully sent to the client, allowing
-+ * us to process further forced updates. */
-+ size_t force_update_offset;
- /* We allow multiple incremental updates or audio capture
- * samples to be queued in output buffer, provided the
- * buffer size doesn't exceed this threshold. The value
---
-2.11.0
-
-
-From f887cf165db20f405cb8805c716bd363aaadf815 Mon Sep 17 00:00:00 2001
-From: "Daniel P. Berrange" <berrange at redhat.com>
-Date: Mon, 18 Dec 2017 19:12:26 +0000
-Subject: [PATCH 12/14] ui: place a hard cap on VNC server output buffer size
-MIME-Version: 1.0
-Content-Type: text/plain; charset=UTF-8
-Content-Transfer-Encoding: 8bit
-
-The previous patches fix problems with throttling of forced framebuffer updates
-and audio data capture that would cause the QEMU output buffer size to grow
-without bound. Those fixes are graceful in that once the client catches up with
-reading data from the server, everything continues operating normally.
-
-There is some data which the server sends to the client that is impractical to
-throttle. Specifically there are various pseudo framebuffer update encodings to
-inform the client of things like desktop resizes, pointer changes, audio
-playback start/stop, LED state and so on. These generally only involve sending
-a very small amount of data to the client, but a malicious guest might be able
-to do things that trigger these changes at a very high rate. Throttling them is
-not practical as missed or delayed events would cause broken behaviour for the
-client.
-
-This patch thus takes a more forceful approach of setting an absolute upper
-bound on the amount of data we permit to be present in the output buffer at
-any time. The previous patch set a threshold for throttling the output buffer
-by allowing an amount of data equivalent to one complete framebuffer update and
-one seconds worth of audio data. On top of this it allowed for one further
-forced framebuffer update to be queued.
-
-To be conservative, we thus take that throttling threshold and multiply it by
-5 to form an absolute upper bound. If this bound is hit during vnc_write() we
-forceably disconnect the client, refusing to queue further data. This limit is
-high enough that it should never be hit unless a malicious client is trying to
-exploit the sever, or the network is completely saturated preventing any sending
-of data on the socket.
-
-This completes the fix for CVE-2017-15124 started in the previous patches.
-
-Signed-off-by: Daniel P. Berrange <berrange at redhat.com>
-Reviewed-by: Darren Kenny <darren.kenny at oracle.com>
-Reviewed-by: Marc-André Lureau <marcandre.lureau at redhat.com>
-Message-id: 20171218191228.31018-12-berrange at redhat.com
-Signed-off-by: Gerd Hoffmann <kraxel at redhat.com>
----
- ui/vnc.c | 29 +++++++++++++++++++++++++++++
- 1 file changed, 29 insertions(+)
-
-diff --git a/ui/vnc.c b/ui/vnc.c
-index 4805ac41d0..e53e84587a 100644
---- a/ui/vnc.c
-+++ b/ui/vnc.c
-@@ -1521,8 +1521,37 @@ gboolean vnc_client_io(QIOChannel *ioc G_GNUC_UNUSED,
- }
-
-
-+/*
-+ * Scale factor to apply to vs->throttle_output_offset when checking for
-+ * hard limit. Worst case normal usage could be x2, if we have a complete
-+ * incremental update and complete forced update in the output buffer.
-+ * So x3 should be good enough, but we pick x5 to be conservative and thus
-+ * (hopefully) never trigger incorrectly.
-+ */
-+#define VNC_THROTTLE_OUTPUT_LIMIT_SCALE 5
-+
- void vnc_write(VncState *vs, const void *data, size_t len)
- {
-+ if (vs->disconnecting) {
-+ return;
-+ }
-+ /* Protection against malicious client/guest to prevent our output
-+ * buffer growing without bound if client stops reading data. This
-+ * should rarely trigger, because we have earlier throttling code
-+ * which stops issuing framebuffer updates and drops audio data
-+ * if the throttle_output_offset value is exceeded. So we only reach
-+ * this higher level if a huge number of pseudo-encodings get
-+ * triggered while data can't be sent on the socket.
-+ *
-+ * NB throttle_output_offset can be zero during early protocol
-+ * handshake, or from the job thread's VncState clone
-+ */
-+ if (vs->throttle_output_offset != 0 &&
-+ vs->output.offset > (vs->throttle_output_offset *
-+ VNC_THROTTLE_OUTPUT_LIMIT_SCALE)) {
-+ vnc_disconnect_start(vs);
-+ return;
-+ }
- buffer_reserve(&vs->output, len);
-
- if (vs->ioc != NULL && buffer_empty(&vs->output)) {
---
-2.11.0
-
-
-From 6aa22a29187e1908f5db738d27c64a9efc8d0bfa Mon Sep 17 00:00:00 2001
-From: "Daniel P. Berrange" <berrange at redhat.com>
-Date: Mon, 18 Dec 2017 19:12:27 +0000
-Subject: [PATCH 13/14] ui: add trace events related to VNC client throttling
-MIME-Version: 1.0
-Content-Type: text/plain; charset=UTF-8
-Content-Transfer-Encoding: 8bit
-
-The VNC client throttling is quite subtle so will benefit from having trace
-points available for live debugging.
-
-Signed-off-by: Daniel P. Berrange <berrange at redhat.com>
-Reviewed-by: Darren Kenny <darren.kenny at oracle.com>
-Reviewed-by: Marc-André Lureau <marcandre.lureau at redhat.com>
-Message-id: 20171218191228.31018-13-berrange at redhat.com
-Signed-off-by: Gerd Hoffmann <kraxel at redhat.com>
----
- ui/trace-events | 7 +++++++
- ui/vnc.c | 23 +++++++++++++++++++++++
- 2 files changed, 30 insertions(+)
-
-diff --git a/ui/trace-events b/ui/trace-events
-index 1a9f126330..85f74f948b 100644
---- a/ui/trace-events
-+++ b/ui/trace-events
-@@ -35,6 +35,13 @@ vnc_client_connect(void *state, void *ioc) "VNC client connect state=%p ioc=%p"
- vnc_client_disconnect_start(void *state, void *ioc) "VNC client disconnect start state=%p ioc=%p"
- vnc_client_disconnect_finish(void *state, void *ioc) "VNC client disconnect finish state=%p ioc=%p"
- vnc_client_io_wrap(void *state, void *ioc, const char *type) "VNC client I/O wrap state=%p ioc=%p type=%s"
-+vnc_client_throttle_threshold(void *state, void *ioc, size_t oldoffset, size_t offset, int client_width, int client_height, int bytes_per_pixel, void *audio_cap) "VNC client throttle threshold state=%p ioc=%p oldoffset=%zu newoffset=%zu width=%d height=%d bpp=%d audio=%p"
-+vnc_client_throttle_incremental(void *state, void *ioc, int job_update, size_t offset) "VNC client throttle incremental state=%p ioc=%p job-update=%d offset=%zu"
-+vnc_client_throttle_forced(void *state, void *ioc, int job_update, size_t offset) "VNC client throttle forced state=%p ioc=%p job-update=%d offset=%zu"
-+vnc_client_throttle_audio(void *state, void *ioc, size_t offset) "VNC client throttle audio state=%p ioc=%p offset=%zu"
-+vnc_client_unthrottle_forced(void *state, void *ioc) "VNC client unthrottle forced offset state=%p ioc=%p"
-+vnc_client_unthrottle_incremental(void *state, void *ioc, size_t offset) "VNC client unthrottle incremental state=%p ioc=%p offset=%zu"
-+vnc_client_output_limit(void *state, void *ioc, size_t offset, size_t threshold) "VNC client output limit state=%p ioc=%p offset=%zu threshold=%zu"
- vnc_auth_init(void *display, int websock, int auth, int subauth) "VNC auth init state=%p websock=%d auth=%d subauth=%d"
- vnc_auth_start(void *state, int method) "VNC client auth start state=%p method=%d"
- vnc_auth_pass(void *state, int method) "VNC client auth passed state=%p method=%d"
-diff --git a/ui/vnc.c b/ui/vnc.c
-index e53e84587a..0a5e629d5d 100644
---- a/ui/vnc.c
-+++ b/ui/vnc.c
-@@ -1011,6 +1011,12 @@ static void vnc_update_throttle_offset(VncState *vs)
- */
- offset = MAX(offset, 1024 * 1024);
-
-+ if (vs->throttle_output_offset != offset) {
-+ trace_vnc_client_throttle_threshold(
-+ vs, vs->ioc, vs->throttle_output_offset, offset, vs->client_width,
-+ vs->client_height, vs->client_pf.bytes_per_pixel, vs->audio_cap);
-+ }
-+
- vs->throttle_output_offset = offset;
- }
-
-@@ -1028,6 +1034,8 @@ static bool vnc_should_update(VncState *vs)
- vs->job_update == VNC_STATE_UPDATE_NONE) {
- return true;
- }
-+ trace_vnc_client_throttle_incremental(
-+ vs, vs->ioc, vs->job_update, vs->output.offset);
- break;
- case VNC_STATE_UPDATE_FORCE:
- /* Only allow forced updates if the pending send queue
-@@ -1042,6 +1050,8 @@ static bool vnc_should_update(VncState *vs)
- vs->job_update == VNC_STATE_UPDATE_NONE) {
- return true;
- }
-+ trace_vnc_client_throttle_forced(
-+ vs, vs->ioc, vs->job_update, vs->force_update_offset);
- break;
- }
- return false;
-@@ -1158,6 +1168,8 @@ static void audio_capture(void *opaque, void *buf, int size)
- vnc_write_u16(vs, VNC_MSG_SERVER_QEMU_AUDIO_DATA);
- vnc_write_u32(vs, size);
- vnc_write(vs, buf, size);
-+ } else {
-+ trace_vnc_client_throttle_audio(vs, vs->ioc, vs->output.offset);
- }
- vnc_unlock_output(vs);
- vnc_flush(vs);
-@@ -1328,6 +1340,7 @@ ssize_t vnc_client_write_buf(VncState *vs, const uint8_t *data, size_t datalen)
- */
- static ssize_t vnc_client_write_plain(VncState *vs)
- {
-+ size_t offset;
- ssize_t ret;
-
- #ifdef CONFIG_VNC_SASL
-@@ -1348,11 +1361,19 @@ static ssize_t vnc_client_write_plain(VncState *vs)
- return 0;
-
- if (ret >= vs->force_update_offset) {
-+ if (vs->force_update_offset != 0) {
-+ trace_vnc_client_unthrottle_forced(vs, vs->ioc);
-+ }
- vs->force_update_offset = 0;
- } else {
- vs->force_update_offset -= ret;
- }
-+ offset = vs->output.offset;
- buffer_advance(&vs->output, ret);
-+ if (offset >= vs->throttle_output_offset &&
-+ vs->output.offset < vs->throttle_output_offset) {
-+ trace_vnc_client_unthrottle_incremental(vs, vs->ioc, vs->output.offset);
-+ }
-
- if (vs->output.offset == 0) {
- if (vs->ioc_tag) {
-@@ -1549,6 +1570,8 @@ void vnc_write(VncState *vs, const void *data, size_t len)
- if (vs->throttle_output_offset != 0 &&
- vs->output.offset > (vs->throttle_output_offset *
- VNC_THROTTLE_OUTPUT_LIMIT_SCALE)) {
-+ trace_vnc_client_output_limit(vs, vs->ioc, vs->output.offset,
-+ vs->throttle_output_offset);
- vnc_disconnect_start(vs);
- return;
- }
---
-2.11.0
-
-
-From 30b80fd5269257f55203b7072c505b4ebaab5115 Mon Sep 17 00:00:00 2001
-From: "Daniel P. Berrange" <berrange at redhat.com>
-Date: Mon, 18 Dec 2017 19:12:28 +0000
-Subject: [PATCH 14/14] ui: mix misleading comments & return types of VNC I/O
- helper methods
-MIME-Version: 1.0
-Content-Type: text/plain; charset=UTF-8
-Content-Transfer-Encoding: 8bit
-
-While the QIOChannel APIs for reading/writing data return ssize_t, with negative
-value indicating an error, the VNC code passes this return value through the
-vnc_client_io_error() method. This detects the error condition, disconnects the
-client and returns 0 to indicate error. Thus all the VNC helper methods should
-return size_t (unsigned), and misleading comments which refer to the possibility
-of negative return values need fixing.
-
-Signed-off-by: Daniel P. Berrange <berrange at redhat.com>
-Reviewed-by: Darren Kenny <darren.kenny at oracle.com>
-Reviewed-by: Marc-André Lureau <marcandre.lureau at redhat.com>
-Message-id: 20171218191228.31018-14-berrange at redhat.com
-Signed-off-by: Gerd Hoffmann <kraxel at redhat.com>
----
- ui/vnc-auth-sasl.c | 8 ++++----
- ui/vnc-auth-sasl.h | 4 ++--
- ui/vnc.c | 29 +++++++++++++++--------------
- ui/vnc.h | 6 +++---
- 4 files changed, 24 insertions(+), 23 deletions(-)
-
-diff --git a/ui/vnc-auth-sasl.c b/ui/vnc-auth-sasl.c
-index 8c1cdde3db..74a5f513f2 100644
---- a/ui/vnc-auth-sasl.c
-+++ b/ui/vnc-auth-sasl.c
-@@ -48,9 +48,9 @@ void vnc_sasl_client_cleanup(VncState *vs)
- }
-
-
--long vnc_client_write_sasl(VncState *vs)
-+size_t vnc_client_write_sasl(VncState *vs)
- {
-- long ret;
-+ size_t ret;
-
- VNC_DEBUG("Write SASL: Pending output %p size %zd offset %zd "
- "Encoded: %p size %d offset %d\n",
-@@ -106,9 +106,9 @@ long vnc_client_write_sasl(VncState *vs)
- }
-
-
--long vnc_client_read_sasl(VncState *vs)
-+size_t vnc_client_read_sasl(VncState *vs)
- {
-- long ret;
-+ size_t ret;
- uint8_t encoded[4096];
- const char *decoded;
- unsigned int decodedLen;
-diff --git a/ui/vnc-auth-sasl.h b/ui/vnc-auth-sasl.h
-index b9d8de1c10..2ae224ee3a 100644
---- a/ui/vnc-auth-sasl.h
-+++ b/ui/vnc-auth-sasl.h
-@@ -65,8 +65,8 @@ struct VncDisplaySASL {
-
- void vnc_sasl_client_cleanup(VncState *vs);
-
--long vnc_client_read_sasl(VncState *vs);
--long vnc_client_write_sasl(VncState *vs);
-+size_t vnc_client_read_sasl(VncState *vs);
-+size_t vnc_client_write_sasl(VncState *vs);
-
- void start_auth_sasl(VncState *vs);
-
-diff --git a/ui/vnc.c b/ui/vnc.c
-index 0a5e629d5d..665a143578 100644
---- a/ui/vnc.c
-+++ b/ui/vnc.c
-@@ -1272,7 +1272,7 @@ void vnc_disconnect_finish(VncState *vs)
- g_free(vs);
- }
-
--ssize_t vnc_client_io_error(VncState *vs, ssize_t ret, Error **errp)
-+size_t vnc_client_io_error(VncState *vs, ssize_t ret, Error **errp)
- {
- if (ret <= 0) {
- if (ret == 0) {
-@@ -1315,9 +1315,9 @@ void vnc_client_error(VncState *vs)
- *
- * Returns the number of bytes written, which may be less than
- * the requested 'datalen' if the socket would block. Returns
-- * -1 on error, and disconnects the client socket.
-+ * 0 on I/O error, and disconnects the client socket.
- */
--ssize_t vnc_client_write_buf(VncState *vs, const uint8_t *data, size_t datalen)
-+size_t vnc_client_write_buf(VncState *vs, const uint8_t *data, size_t datalen)
- {
- Error *err = NULL;
- ssize_t ret;
-@@ -1335,13 +1335,13 @@ ssize_t vnc_client_write_buf(VncState *vs, const uint8_t *data, size_t datalen)
- * will switch the FD poll() handler back to read monitoring.
- *
- * Returns the number of bytes written, which may be less than
-- * the buffered output data if the socket would block. Returns
-- * -1 on error, and disconnects the client socket.
-+ * the buffered output data if the socket would block. Returns
-+ * 0 on I/O error, and disconnects the client socket.
- */
--static ssize_t vnc_client_write_plain(VncState *vs)
-+static size_t vnc_client_write_plain(VncState *vs)
- {
- size_t offset;
-- ssize_t ret;
-+ size_t ret;
-
- #ifdef CONFIG_VNC_SASL
- VNC_DEBUG("Write Plain: Pending output %p size %zd offset %zd. Wait SSF %d\n",
-@@ -1442,9 +1442,9 @@ void vnc_read_when(VncState *vs, VncReadEvent *func, size_t expecting)
- *
- * Returns the number of bytes read, which may be less than
- * the requested 'datalen' if the socket would block. Returns
-- * -1 on error, and disconnects the client socket.
-+ * 0 on I/O error or EOF, and disconnects the client socket.
- */
--ssize_t vnc_client_read_buf(VncState *vs, uint8_t *data, size_t datalen)
-+size_t vnc_client_read_buf(VncState *vs, uint8_t *data, size_t datalen)
- {
- ssize_t ret;
- Error *err = NULL;
-@@ -1460,12 +1460,13 @@ ssize_t vnc_client_read_buf(VncState *vs, uint8_t *data, size_t datalen)
- * when not using any SASL SSF encryption layers. Will read as much
- * data as possible without blocking.
- *
-- * Returns the number of bytes read. Returns -1 on error, and
-- * disconnects the client socket.
-+ * Returns the number of bytes read, which may be less than
-+ * the requested 'datalen' if the socket would block. Returns
-+ * 0 on I/O error or EOF, and disconnects the client socket.
- */
--static ssize_t vnc_client_read_plain(VncState *vs)
-+static size_t vnc_client_read_plain(VncState *vs)
- {
-- ssize_t ret;
-+ size_t ret;
- VNC_DEBUG("Read plain %p size %zd offset %zd\n",
- vs->input.buffer, vs->input.capacity, vs->input.offset);
- buffer_reserve(&vs->input, 4096);
-@@ -1491,7 +1492,7 @@ static void vnc_jobs_bh(void *opaque)
- */
- static int vnc_client_read(VncState *vs)
- {
-- ssize_t ret;
-+ size_t ret;
-
- #ifdef CONFIG_VNC_SASL
- if (vs->sasl.conn && vs->sasl.runSSF)
-diff --git a/ui/vnc.h b/ui/vnc.h
-index 3f4cd4d93d..0c33a5f7fe 100644
---- a/ui/vnc.h
-+++ b/ui/vnc.h
-@@ -524,8 +524,8 @@ gboolean vnc_client_io(QIOChannel *ioc,
- GIOCondition condition,
- void *opaque);
-
--ssize_t vnc_client_read_buf(VncState *vs, uint8_t *data, size_t datalen);
--ssize_t vnc_client_write_buf(VncState *vs, const uint8_t *data, size_t datalen);
-+size_t vnc_client_read_buf(VncState *vs, uint8_t *data, size_t datalen);
-+size_t vnc_client_write_buf(VncState *vs, const uint8_t *data, size_t datalen);
-
- /* Protocol I/O functions */
- void vnc_write(VncState *vs, const void *data, size_t len);
-@@ -544,7 +544,7 @@ uint32_t read_u32(uint8_t *data, size_t offset);
-
- /* Protocol stage functions */
- void vnc_client_error(VncState *vs);
--ssize_t vnc_client_io_error(VncState *vs, ssize_t ret, Error **errp);
-+size_t vnc_client_io_error(VncState *vs, ssize_t ret, Error **errp);
-
- void start_client_init(VncState *vs);
- void start_auth_vnc(VncState *vs);
---
-2.11.0
diff --git a/meta/recipes-devtools/qemu/qemu_2.11.0.bb b/meta/recipes-devtools/qemu/qemu_2.11.1.bb
similarity index 91%
rename from meta/recipes-devtools/qemu/qemu_2.11.0.bb
rename to meta/recipes-devtools/qemu/qemu_2.11.1.bb
index 10760dc..f0e20cc 100644
--- a/meta/recipes-devtools/qemu/qemu_2.11.0.bb
+++ b/meta/recipes-devtools/qemu/qemu_2.11.1.bb
@@ -22,7 +22,6 @@ SRC_URI = "http://wiki.qemu-project.org/download/${BP}.tar.bz2 \
file://apic-fixup-fallthrough-to-PIC.patch \
file://linux-user-Fix-webkitgtk-hangs-on-32-bit-x86-target.patch \
file://memfd.patch \
- file://CVE-2017-15124.patch \
"
UPSTREAM_CHECK_REGEX = "qemu-(?P<pver>\d+\..*)\.tar"
@@ -32,8 +31,8 @@ SRC_URI_append_class-native = " \
file://cpus.c-qemu_cpu_kick_thread_debugging.patch \
"
-SRC_URI[md5sum] = "335994a755bc655e88a87aeb36bfc0b9"
-SRC_URI[sha256sum] = "c4f034c7665a84a1c3be72c8da37f3c31ec063475699df062ab646d8b2e17fcb"
+SRC_URI[md5sum] = "61cf862b6007eba4ac98247776af2e27"
+SRC_URI[sha256sum] = "d9df2213ceed32e91dab7bc9dd19c1af83f91ba72c7aeef7605dfaaf81732ccb"
COMPATIBLE_HOST_mipsarchn32 = "null"
COMPATIBLE_HOST_mipsarchn64 = "null"
--
To stop receiving notification emails like this one, please contact
the administrator of this repository.
More information about the Openembedded-commits
mailing list