From patchwork Mon Jun 26 15:36:50 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Ross Lagerwall X-Patchwork-Id: 9809961 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 1C8A7603D7 for ; Mon, 26 Jun 2017 15:40:34 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 206D92865B for ; Mon, 26 Jun 2017 15:40:34 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 151FC28688; Mon, 26 Jun 2017 15:40:34 +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 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 4A5FD2865B for ; Mon, 26 Jun 2017 15:40:32 +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 1dPW5G-0000mG-NI; Mon, 26 Jun 2017 15:37:50 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xenproject.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dPW5F-0000mA-RK for xen-devel@lists.xen.org; Mon, 26 Jun 2017 15:37:49 +0000 Received: from [85.158.139.211] by server-17.bemta-5.messagelabs.com id 67/EE-19466-D4A21595; Mon, 26 Jun 2017 15:37:49 +0000 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrHLMWRWlGSWpSXmKPExsXitHRDpK6PVmC kwdLpGhZLPi5mcWD0OLr7N1MAYxRrZl5SfkUCa8aUg82MBTMUKs5PmMnSwNgp1cXIySEh4C/R vXA1G4jNJmAgcevSd2YQW0RAVmJ11xz2LkYuDmaBqcwSd/5fZQJJCAsESNxa1g5mswioSryf0 MUCYvMK2Elcn72HEWKonMTS7dfBBgkJqEm8XX4GqkZQ4uTMJ2A2s4CExMEXL5gnMHLPQpKahS S1gJFpFaNGcWpRWWqRrpGFXlJRZnpGSW5iZo6uoYGpXm5qcXFiempOYlKxXnJ+7iZGYDjUMzA w7mDsW+V3iFGSg0lJlJfjSUCkEF9SfkplRmJxRnxRaU5q8SFGGQ4OJQneO+qBkUKCRanpqRVp mTnAwIRJS3DwKInwiv4FauUtLkjMLc5Mh0idYlSUEueV0wTqEwBJZJTmwbXBouESo6yUMC8jA wODEE9BalFuZgmq/CtGcQ5GJWFeL5ApPJl5JXDTXwEtZgJazDIPbHFJIkJKqoFR3muNlf6lzo 0Xg6dXbf/6uX7hXNvi+S9uTOlQTffPabvoGKBRvET05qdpXWvTdplrP3e4u7j0kLzSsyq1U1I /Ql85JdxML5B/8vT7fCOXddeWdLwW9/3novUxyaAsrvympMIs656cuRft009EsifOneT+X8vJ /YFbxbK3l9Ny2qZcdHvcdyFMiaU4I9FQi7moOBEALfxR+oECAAA= X-Env-Sender: prvs=343118cd4=ross.lagerwall@citrix.com X-Msg-Ref: server-7.tower-206.messagelabs.com!1498491466!102246920!1 X-Originating-IP: [66.165.176.89] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n, received_headers: No Received headers X-StarScan-Received: X-StarScan-Version: 9.4.19; banners=-,-,- X-VirusChecked: Checked Received: (qmail 33879 invoked from network); 26 Jun 2017 15:37:48 -0000 Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89) by server-7.tower-206.messagelabs.com with RC4-SHA encrypted SMTP; 26 Jun 2017 15:37:48 -0000 X-IronPort-AV: E=Sophos;i="5.39,396,1493683200"; d="scan'208";a="429375477" From: Ross Lagerwall To: Date: Mon, 26 Jun 2017 16:36:50 +0100 Message-ID: <20170626153650.23017-1-ross.lagerwall@citrix.com> X-Mailer: git-send-email 2.9.4 MIME-Version: 1.0 Cc: Lars Kurth , Stefano Stabellini , George Dunlap , Andrew Cooper , Wei Liu , Ian Jackson , Ross Lagerwall , Julien Grall , Jan Beulich Subject: [Xen-devel] [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 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. 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 out the scope of security support: * 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. * 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. * Bugs in livepatch-build-tools creating 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. * 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. * 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. * 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 prevent the application of a live patch, it shall be treated as a security issue. There are also some generic security questions which it is 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. Signed-off-by: Ross Lagerwall --- xen/common/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/xen/common/Kconfig b/xen/common/Kconfig index dc8e876..876086c 100644 --- a/xen/common/Kconfig +++ b/xen/common/Kconfig @@ -226,7 +226,7 @@ config CRYPTO bool config LIVEPATCH - bool "Live patching support (TECH PREVIEW)" + bool "Live patching support" default n depends on HAS_BUILD_ID = "y" ---help---