From patchwork Tue Aug 29 14:44:14 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Konrad Rzeszutek Wilk X-Patchwork-Id: 9927573 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id 5FE496022E for ; Tue, 29 Aug 2017 14:47:06 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 4E25528975 for ; Tue, 29 Aug 2017 14:47:06 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 418E12897C; Tue, 29 Aug 2017 14:47:06 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-4.2 required=2.0 tests=BAYES_00, RCVD_IN_DNSWL_MED, UNPARSEABLE_RELAY autolearn=ham version=3.3.1 Received: from lists.xenproject.org (lists.xenproject.org [192.237.175.120]) (using TLSv1.2 with cipher AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.wl.linuxfoundation.org (Postfix) with ESMTPS id 91D0C28975 for ; Tue, 29 Aug 2017 14:47:05 +0000 (UTC) Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dmhkm-0001sr-Os; Tue, 29 Aug 2017 14:44:32 +0000 Received: from mail6.bemta6.messagelabs.com ([193.109.254.103]) by lists.xenproject.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dmhkl-0001sl-Jq for xen-devel@lists.xen.org; Tue, 29 Aug 2017 14:44:31 +0000 Received: from [193.109.254.147] by server-10.bemta-6.messagelabs.com id 05/55-03642-ECD75A95; Tue, 29 Aug 2017 14:44:30 +0000 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrKIsWRWlGSWpSXmKPExsXSO6nOVfdc7dJ Ig6uSFks+LmZxYPQ4uvs3UwBjFGtmXlJ+RQJrxs0Fr9kKjhtUfLmwnqmBsVGji5GLQ0hgMpPE 6n0rmCGcv4wS+6Y+Y4NwNjJKdEz4yA7hdDJKTDywkbWLkZODRUBVYsn3hUAJDg42AROJN6scQ cIiAjoSV/e+YAWpZxaYwSwxcfUdMEdYYC6jxJfl29hBqngFTCWWXX8MNXUGi8SNxSugEoISJ2 c+YQGxmQW0JG78e8kEsoFZQFpi+T8OEJNTwE7i+jQXkApRAWWJeftWsYHYEgLGEu1vL7JNYBS chWTQLCSDZiEMWsDIvIpRozi1qCy1SNfQSC+pKDM9oyQ3MTNH19DATC83tbg4MT01JzGpWC85 P3cTIzBwGYBgB+PljQGHGCU5mJREeeeWL40U4kvKT6nMSCzOiC8qzUktPsQow8GhJMG7owYoJ 1iUmp5akZaZA4whmLQEB4+SCO9BkDRvcUFibnFmOkTqFKMxx5M3238zcbS8BZJCLHn5ealS4r x5IKUCIKUZpXlwg2CxfYlRVkqYlxHoNCGegtSi3MwSVPlXjOIcjErCEPfwZOaVwO17BXQKE9A psV5gp5QkIqSkGhgXmv8+/FP1n8eZYzPm3lxSzCsRyqT+2ful8neufUta97zNkdHePud+d8C6 bmGllaZicm63FnfNeFSp+X79Zra3VYzT2XT4v1l/UdPSOz01OPBTC6+cwoT3x+IYQjKnv+Zls ih9d3H9/mbp/8zaG/02Lqydwq4R0ln8Wfv9M3supbkP98pZ+/YrsRRnJBpqMRcVJwIA9ll2h+ gCAAA= X-Env-Sender: konrad.wilk@oracle.com X-Msg-Ref: server-8.tower-27.messagelabs.com!1504017868!103096036!1 X-Originating-IP: [141.146.126.69] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n X-StarScan-Received: X-StarScan-Version: 9.4.45; banners=-,-,- X-VirusChecked: Checked Received: (qmail 44660 invoked from network); 29 Aug 2017 14:44:29 -0000 Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com) (141.146.126.69) by server-8.tower-27.messagelabs.com with DHE-RSA-AES256-GCM-SHA384 encrypted SMTP; 29 Aug 2017 14:44:29 -0000 Received: from aserv0022.oracle.com (aserv0022.oracle.com [141.146.126.234]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id v7TEiM1F008551 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 29 Aug 2017 14:44:22 GMT Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236]) by aserv0022.oracle.com (8.14.4/8.14.4) with ESMTP id v7TEiKvT032339 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 29 Aug 2017 14:44:20 GMT Received: from abhmp0013.oracle.com (abhmp0013.oracle.com [141.146.116.19]) by aserv0122.oracle.com (8.14.4/8.14.4) with ESMTP id v7TEiIsP019038; Tue, 29 Aug 2017 14:44:19 GMT Received: from x230.dumpdata.com (/10.154.189.59) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 29 Aug 2017 07:44:18 -0700 Date: Tue, 29 Aug 2017 10:44:14 -0400 From: Konrad Rzeszutek Wilk To: George Dunlap Message-ID: <20170829144414.GA5224@x230.dumpdata.com> References: <19a49667-21fb-b073-14c0-2be8175563ec@citrix.com> <587a96d7-ed4f-cb37-f790-d8b954d0b284@citrix.com> <20170806000747.GU17252@char.us.oracle.com> <6c849c8d-1795-d23e-e69d-6f4087e77dc3@citrix.com> <59888E7702000078001039F0@prv-mh.provo.novell.com> <36ad3a19-fd11-b1dd-3aa9-361172d83814@citrix.com> <598AD786020000780016DF89@prv-mh.provo.novell.com> <599AE9330200007800171877@prv-mh.provo.novell.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.8.3 (2017-05-23) X-Source-IP: aserv0022.oracle.com [141.146.126.234] Cc: Lars Kurth , Stefano Stabellini , Wei Liu , Andrew Cooper , Ian Jackson , "xen-devel@lists.xen.org" , Ross Lagerwall , Julien Grall , Jan Beulich Subject: Re: [Xen-devel] Is:livepatch-build-tools.git declare it supported? Was:Re: [PATCH for-4.9] livepatch: Declare live patching as a supported feature X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xen.org Sender: "Xen-devel" X-Virus-Scanned: ClamAV using ClamSMTP .giant snip.. > Indeed; and as I think I said before, I think we need to move forward > with getting a statement on livepatching in, and since most of the > voices involved in this conversation seem to be in favor of saying > livepatch-tools are *not* supported, I won't object. I'm only still Thank you. As such, here is the patch. Would folks like me to repost it, or OK with Acking/Reviewing it as such? I think the point 3) succinctly explains the position that has been so hotly debated. I can of course expand it, but not sure if it makes sense? From f968f003d36ac2b9d1b670b34bbe2a1222830138 Mon Sep 17 00:00:00 2001 From: Ross Lagerwall Date: Wed, 28 Jun 2017 17:13:44 +0100 Subject: [PATCH v3] livepatch: Declare live patching as a supported feature See docs/features/livepatch.pandoc for the details. Signed-off-by: Ross Lagerwall Signed-off-by: Konrad Rzeszutek Wilk --- v2: - Moved it into a feature document. - Clarified a few bits and pieces based on feedback. v3: - default X86 --- docs/features/livepatch.pandoc | 103 +++++++++++++++++++++++++++++++++++++++++ xen/common/Kconfig | 4 +- 2 files changed, 105 insertions(+), 2 deletions(-) create mode 100644 docs/features/livepatch.pandoc diff --git a/docs/features/livepatch.pandoc b/docs/features/livepatch.pandoc new file mode 100644 index 0000000000..faaf2d1e77 --- /dev/null +++ b/docs/features/livepatch.pandoc @@ -0,0 +1,103 @@ +% Live Patching +% Revision 1 + +\clearpage + +# Basics + +---------------- ---------------------------------------------------- + Status: **Supported** + + Architecture: x86 + + Component: Hypervisor, toolstack +---------------- ---------------------------------------------------- + + +# Details + +Xen Live Patching has been available as tech preview feature since Xen +4.7 and has now had a couple of releases to stabilize. Xen Live patching +has been used by multiple vendors to fix several real-world security +issues without any severe bugs encountered. Additionally, there are now +tests in OSSTest that test live patching to ensure that no regressions +are introduced. + +Based on the amount of testing and usage it has had, we are ready to +declare live patching as a 'Supported' feature on x86. + +Live patching is slightly peculiar when it comes to support because it +allows the host administrator to break their system rather easily +depending on the content of the live patch. Because of this, it is +worth detailing the scope of security support: + +1) Unprivileged access to live patching operations: + Live patching operations should only be accessible to privileged + guests and it shall be treated as a security issue if this is not + the case. + +2) Bugs in the patch-application code such that vulnerabilities exist + after application: + If a correct live patch is loaded but it is not applied correctly + such that it might result in an insecure system (e.g. not all + functions are patched), it shall be treated as a security issue. + +3) Bugs in livepatch-build-tools creating an incorrect live patch that + results in an insecure host: + If livepatch-build-tools creates an incorrect live patch that + results in an insecure host, this shall not be considered a security + issue. There are too many OSes and toolchains to consider supporting + this. A live patch should be checked to verify that it is valid + before loading. + +4) Loading an incorrect live patch that results in an insecure host or + host crash: + If a live patch (whether created using livepatch-build-tools or some + alternative) is loaded and it results in an insecure host or host + crash due to the content of the live patch being incorrect or the + issue being inappropriate to live patch, this is not considered as a + security issue. + +5) Bugs in the live patch parsing code (the ELF loader): + Bugs in the live patch parsing code such as out-of-bounds reads + caused by invalid ELF files are not considered to be security issues + because the it can only be triggered by a privileged domain. + +6) Bugs which allow a guest to prevent the application of a livepatch: + A guest should not be able to prevent the application of a live + patch. If an unprivileged guest can somehow prevent the application + of a live patch despite pausing it (xl pause ...), it shall be + treated as a security issue. + +Note: It is expected that live patches are tested in a test environment +before being used in production to avoid unexpected issues. In +particular, to avoid the issues described by (3), (4), & (5). + +There are also some generic security questions which are worth asking: + +1) Is guest->host privilege escalation possible? + +The new live patching sysctl subops are only accessible to privileged +domains and this is tested by OSSTest with an XTF test. +There is a caveat -- an incorrect live patch can introduce a guest->host +privilege escalation. + +2) Is guest user->guest kernel escalation possible? + +No, although an incorrect live patch can introduce a guest user->guest +kernel privilege escalation. + +3) Is there any information leakage? + +The new live patching sysctl subops are only accessible to privileged +domains so it is not possible for an unprivileged guest to access the +list of loaded live patches. This is tested by OSSTest with an XTF test. +There is a caveat -- an incorrect live patch can introduce an +information leakage. + +4) Can a Denial-of-Service be triggered? + +There are no known ways that an unprivileged guest can prevent a live +patch from being loaded. +Once again, there is a caveat that an incorrect live patch can introduce +an arbitrary denial of service. diff --git a/xen/common/Kconfig b/xen/common/Kconfig index dc8e876439..e9bb849298 100644 --- a/xen/common/Kconfig +++ b/xen/common/Kconfig @@ -226,8 +226,8 @@ config CRYPTO bool config LIVEPATCH - bool "Live patching support (TECH PREVIEW)" - default n + bool "Live patching support" + default X86 depends on HAS_BUILD_ID = "y" ---help--- Allows a running Xen hypervisor to be dynamically patched using