Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp3824009imu; Mon, 10 Dec 2018 08:22:25 -0800 (PST) X-Google-Smtp-Source: AFSGD/VqZZegCr2hFyvQQjPzJrgjAOrPfJGk1OCXd6NFoT1ljX238jMHhUVx5IwflhBekxsndGak X-Received: by 2002:a62:2044:: with SMTP id g65mr12841984pfg.127.1544458945441; Mon, 10 Dec 2018 08:22:25 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1544458945; cv=none; d=google.com; s=arc-20160816; b=NEzeNOz+qfKo5UqcSaqPoEiyagQnzO33Oz8pzmGMIDFCkNX+vhmW75WFEOcN6RGi1k LpRAVbDnk44jiHod7iLo+sxWe+X1Eoi1jfrNiR4Uxuz3EQcFfwqJcl+Qbzto0FoC6FPa RT8OvdfU05G8lgVEera1/v7ZmRKgfyorK23KcUKpMHc6Yud4Ff48SbK6rqrmX8IQhcJ3 11C4+doIw7Op5SjurfBoSVRZb+nhWr+cc9u/8OuG4tZLd00yJAsfxa4xZQ8v8j7+RgPL qRht9fegdL9hp4MWIynsEBI/1kQcnYIW7uDleUELeBeXVfq8PHI801u1L0J4xjV5wFwt mEtw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=B1kNIOtHuPHIvFqGl0pmIbDfxKenM5VfA0dtJYMJero=; b=wdernWjuGVBuH6D8tkrgtOcplsEVnxJ2NBPQnYj0OXDPAEj5KebhcShiQBb/09V5LZ L36C0GzTw4pqfoLzIhC1ZWCF+dr+DoS42/4D1/RA70EZcdZ6qk3XDK+F2PDkajcEzZnh grxcKq0+gpO2nEEqVzT4jMfkNFsYFhH3Q1in+2r+oIlZMsjN1FMkvn4x2XmhgQO9i18s fBChRe8m2c5ryzyAOPpGh8j/Rek/UGjWXX3/gBWTfcB0TmJ1A127Ht52bt5axfVpy20F l4B0pcNagO0Nbrkq0yHYT5zf2I/yWzLZxnjEZx/7cDXOL6JcqT29eNr5JcW5YwGMUi7E 47tg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id j22si10867147pfi.252.2018.12.10.08.22.10; Mon, 10 Dec 2018 08:22:25 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728024AbeLJPPV (ORCPT + 99 others); Mon, 10 Dec 2018 10:15:21 -0500 Received: from smtp.eu.citrix.com ([185.25.65.24]:59901 "EHLO SMTP.EU.CITRIX.COM" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727437AbeLJPPV (ORCPT ); Mon, 10 Dec 2018 10:15:21 -0500 X-IronPort-AV: E=Sophos;i="5.56,338,1539648000"; d="scan'208";a="83056576" Date: Mon, 10 Dec 2018 16:14:47 +0100 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: Dongli Zhang CC: , , , , Subject: Re: [PATCH 1/1] xen/blkback: rework connect_ring() to avoid inconsistent xenstore 'ring-page-order' set by malicious blkfront Message-ID: <20181210151447.jezcmwn6lzyq5xzd@mac> References: <1544156284-7756-1-git-send-email-dongli.zhang@oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: <1544156284-7756-1-git-send-email-dongli.zhang@oracle.com> User-Agent: NeoMutt/20180716 X-ClientProxiedBy: AMSPEX02CAS02.citrite.net (10.69.22.113) To AMSPEX02CL02.citrite.net (10.69.22.126) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Dec 07, 2018 at 12:18:04PM +0800, Dongli Zhang wrote: > The xenstore 'ring-page-order' is used globally for each blkback queue and > therefore should be read from xenstore only once. However, it is obtained > in read_per_ring_refs() which might be called multiple times during the > initialization of each blkback queue. > > If the blkfront is malicious and the 'ring-page-order' is set in different > value by blkfront every time before blkback reads it, this may end up at > the "WARN_ON(i != (XEN_BLKIF_REQS_PER_PAGE * blkif->nr_ring_pages));" in > xen_blkif_disconnect() when frontend is destroyed. > > This patch reworks connect_ring() to read xenstore 'ring-page-order' only > once. > > Signed-off-by: Dongli Zhang > --- > drivers/block/xen-blkback/xenbus.c | 49 ++++++++++++++++++++++++-------------- > 1 file changed, 31 insertions(+), 18 deletions(-) > > diff --git a/drivers/block/xen-blkback/xenbus.c b/drivers/block/xen-blkback/xenbus.c > index a4bc74e..4a8ce20 100644 > --- a/drivers/block/xen-blkback/xenbus.c > +++ b/drivers/block/xen-blkback/xenbus.c > @@ -919,14 +919,15 @@ static void connect(struct backend_info *be) > /* > * Each ring may have multi pages, depends on "ring-page-order". > */ > -static int read_per_ring_refs(struct xen_blkif_ring *ring, const char *dir) > +static int read_per_ring_refs(struct xen_blkif_ring *ring, const char *dir, > + bool use_ring_page_order) Why not change the order of read_per_ring_refs so that it tries to fetch the grant references from "ring-refXX" first and then fallback to reading the legacy grant reference if nr_ring_pages == 1? This will avoid having to pass an extra parameter to it. > { > unsigned int ring_ref[XENBUS_MAX_RING_GRANTS]; > struct pending_req *req, *n; > int err, i, j; > struct xen_blkif *blkif = ring->blkif; > struct xenbus_device *dev = blkif->be->dev; > - unsigned int ring_page_order, nr_grefs, evtchn; > + unsigned int nr_grefs, evtchn; > > err = xenbus_scanf(XBT_NIL, dir, "event-channel", "%u", > &evtchn); > @@ -936,28 +937,18 @@ static int read_per_ring_refs(struct xen_blkif_ring *ring, const char *dir) > return err; > } > > - err = xenbus_scanf(XBT_NIL, dev->otherend, "ring-page-order", "%u", > - &ring_page_order); > - if (err != 1) { > + nr_grefs = blkif->nr_ring_pages; > + > + if (!use_ring_page_order) { > err = xenbus_scanf(XBT_NIL, dir, "ring-ref", "%u", &ring_ref[0]); > if (err != 1) { > err = -EINVAL; > xenbus_dev_fatal(dev, err, "reading %s/ring-ref", dir); > return err; > } > - nr_grefs = 1; > } else { > unsigned int i; > > - if (ring_page_order > xen_blkif_max_ring_order) { > - err = -EINVAL; > - xenbus_dev_fatal(dev, err, "%s/request %d ring page order exceed max:%d", > - dir, ring_page_order, > - xen_blkif_max_ring_order); > - return err; > - } > - > - nr_grefs = 1 << ring_page_order; > for (i = 0; i < nr_grefs; i++) { > char ring_ref_name[RINGREF_NAME_LEN]; > > @@ -972,7 +963,6 @@ static int read_per_ring_refs(struct xen_blkif_ring *ring, const char *dir) > } > } > } > - blkif->nr_ring_pages = nr_grefs; > > for (i = 0; i < nr_grefs * XEN_BLKIF_REQS_PER_PAGE; i++) { > req = kzalloc(sizeof(*req), GFP_KERNEL); > @@ -1030,6 +1020,8 @@ static int connect_ring(struct backend_info *be) > size_t xspathsize; > const size_t xenstore_path_ext_size = 11; /* sufficient for "/queue-NNN" */ > unsigned int requested_num_queues = 0; > + bool use_ring_page_order = false; > + unsigned int ring_page_order; > > pr_debug("%s %s\n", __func__, dev->otherend); > > @@ -1075,8 +1067,28 @@ static int connect_ring(struct backend_info *be) > be->blkif->nr_rings, be->blkif->blk_protocol, protocol, > pers_grants ? "persistent grants" : ""); > > + err = xenbus_scanf(XBT_NIL, dev->otherend, "ring-page-order", "%u", > + &ring_page_order); You can use xenbus_read_unsigned IMO, which will simplify the logic below a little bit. Thanks, Roger.