From patchwork Mon Jan 4 13:06:32 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: =?utf-8?q?Marek_Marczykowski-G=C3=B3recki?= X-Patchwork-Id: 7948101 Return-Path: X-Original-To: patchwork-xen-devel@patchwork.kernel.org Delivered-To: patchwork-parsemail@patchwork2.web.kernel.org Received: from mail.kernel.org (mail.kernel.org [198.145.29.136]) by patchwork2.web.kernel.org (Postfix) with ESMTP id A0F24BEEE5 for ; Mon, 4 Jan 2016 13:09:37 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id 70DCD2012B for ; Mon, 4 Jan 2016 13:09:35 +0000 (UTC) Received: from lists.xen.org (lists.xenproject.org [50.57.142.19]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 1581A20034 for ; Mon, 4 Jan 2016 13:09:33 +0000 (UTC) Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1aG4qS-00016F-Re; Mon, 04 Jan 2016 13:06:44 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1aG4qR-000168-1c for xen-devel@lists.xen.org; Mon, 04 Jan 2016 13:06:43 +0000 Received: from [85.158.137.68] by server-11.bemta-3.messagelabs.com id 7B/7D-32641-26E6A865; Mon, 04 Jan 2016 13:06:42 +0000 X-Env-Sender: marmarek@invisiblethingslab.com X-Msg-Ref: server-15.tower-31.messagelabs.com!1451912796!13498331!1 X-Originating-IP: [66.111.4.28] X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG X-StarScan-Received: X-StarScan-Version: 7.35.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 22792 invoked from network); 4 Jan 2016 13:06:36 -0000 Received: from out4-smtp.messagingengine.com (HELO out4-smtp.messagingengine.com) (66.111.4.28) by server-15.tower-31.messagelabs.com with DHE-RSA-AES256-GCM-SHA384 encrypted SMTP; 4 Jan 2016 13:06:36 -0000 Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id D566320BB6 for ; Mon, 4 Jan 2016 08:06:35 -0500 (EST) Received: from frontend2 ([10.202.2.161]) by compute3.internal (MEProxy); Mon, 04 Jan 2016 08:06:35 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= invisiblethingslab.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-sasl-enc :x-sasl-enc; s=mesmtp; bh=nWPR3A3LT7RjTmQc3YD5NZvgmFU=; b=atpgpA UoPbHoHJMy639t30MEN0wM0zaYKNpnpE5jSx6CpXW/Sk8vwKYflwbAayYtdtqxtj mrn2Fq4Cjtx+3gkTHCieSEi02mfQDyIEDWuotmL3SESfw35iVdqRpNA7xLJEkAjH bZmzIWzAf1EZdL+lr4wE3Q2FPkx/1JNT4oAGY= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-sasl-enc :x-sasl-enc; s=smtpout; bh=nWPR3A3LT7RjTmQc3YD5NZvgmFU=; b=RUAq5 ya1WW6h8Hom+9WkV3SU/4f/BO/aBu9cF+y6aAzdBlUNetaVPg0iXlWj8cTQ8Xwys vtniOe580w1oeh8v9Ba2sxiTgj9fScdPBpSibiZGyJGW5NklR/N+4FIGNZ2GQ7Cg Ui4vtzNjxtdwT3tTlrUaC7t8JhGomnFsq1suSU= X-Sasl-enc: 0i9VYRcpzz3F3G0+rtMGvLgnDYq0JT7tZReBFgrgDs4H 1451912794 Received: from mail-itl (89-70-93-48.dynamic.chello.pl [89.70.93.48]) by mail.messagingengine.com (Postfix) with ESMTPA id 6E4976800AA; Mon, 4 Jan 2016 08:06:34 -0500 (EST) Date: Mon, 4 Jan 2016 14:06:32 +0100 From: Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?= To: Eric Shelton Message-ID: <20160104130632.GF4892@mail-itl> References: MIME-Version: 1.0 In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Cc: security@xen.org, "xen-devel@lists.xen.org" , Stefano Stabellini Subject: Re: [Xen-devel] Xen Security Advisory 155 (CVE-2015-8550) - paravirtualized drivers incautious about shared memory X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org X-Spam-Status: No, score=-4.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, RCVD_IN_DNSWL_MED, T_DKIM_INVALID, UNPARSEABLE_RELAY autolearn=unavailable version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP On Tue, Dec 22, 2015 at 10:06:25AM -0500, Eric Shelton wrote: > The XSA mentions that "PV frontend patches will be developed and > released (publicly) after the embargo date." Has anything been done > towards this that should also be incorporated into MiniOS? On a > system utilizing a "driver domain," where a backend is running on a > domain that is considered unprivileged and untrusted (such as the > example described in http://wiki.xenproject.org/wiki/Driver_Domain), > it seems XSA-155-style double fetch vulnerabilities in the frontends > are also a potential security concern, and should be eliminated. > However, perhaps that does not include pcifront, since pciback would > always be running in dom0. And BTW the same applies to Linux frontends, for which also I haven't seen any public development. In attachment my email to xen-security-issues-discuss list (sent during embargo), with patches attached there. I haven't got any response. PS Dropping minios-devel diff --git a/include/xen/interface/io/ring.h b/include/xen/interface/io/ring.h index 7dc685b..312415c 100644 --- a/include/xen/interface/io/ring.h +++ b/include/xen/interface/io/ring.h @@ -198,6 +198,20 @@ struct __name##_back_ring { \ #define RING_GET_RESPONSE(_r, _idx) \ (&((_r)->sring->ring[((_idx) & (RING_SIZE(_r) - 1))].rsp)) +/* + * Get a local copy of a response. + * + * Use this in preference to RING_GET_RESPONSE() so all processing is + * done on a local copy that cannot be modified by the other end. + * + * Note that https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58145 may cause this + * to be ineffective where _rsp is a struct which consists of only bitfields. + */ +#define RING_COPY_RESPONSE(_r, _idx, _rsp) do { \ + /* Use volatile to force the copy into _rsp. */ \ + *(_rsp) = *(volatile typeof(_rsp))RING_GET_RESPONSE(_r, _idx); \ +} while (0) + /* Loop termination condition: Would the specified index overflow the ring? */ #define RING_REQUEST_CONS_OVERFLOW(_r, _cons) \ (((_cons) - (_r)->rsp_prod_pvt) >= RING_SIZE(_r))