All of lore.kernel.org
 help / color / mirror / Atom feed
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: George Dunlap <george.dunlap@citrix.com>
Cc: Lars Kurth <lars.kurth@citrix.com>,
	Stefano Stabellini <sstabellini@kernel.org>,
	Wei Liu <liuw@liuw.name>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Ian Jackson <ian.jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Ross Lagerwall <ross.lagerwall@citrix.com>,
	Julien Grall <julien.grall@arm.com>,
	Jan Beulich <JBeulich@suse.com>
Subject: Re: Is:livepatch-build-tools.git declare it supported? Was:Re: [PATCH for-4.9] livepatch: Declare live patching as a supported feature
Date: Tue, 29 Aug 2017 10:44:14 -0400	[thread overview]
Message-ID: <20170829144414.GA5224@x230.dumpdata.com> (raw)
In-Reply-To: <fabbcef7-a7ad-f5aa-67a1-d79ea73a32f5@citrix.com>

.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 <ross.lagerwall@citrix.com>
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 <ross.lagerwall@citrix.com>
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>

--
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
-- 
2.13.0


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

  parent reply	other threads:[~2017-08-29 14:44 UTC|newest]

Thread overview: 45+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-06-26 15:36 [PATCH for-4.9] livepatch: Declare live patching as a supported feature Ross Lagerwall
2017-06-26 16:39 ` Andrew Cooper
2017-06-26 16:50   ` George Dunlap
2017-06-26 16:53     ` Ian Jackson
2017-06-26 17:18     ` Andrew Cooper
2017-06-27  8:37       ` George Dunlap
2017-06-27 10:47         ` Andrew Cooper
2017-06-27 10:49           ` George Dunlap
2017-06-26 16:50   ` Ross Lagerwall
2017-06-26 17:04     ` Andrew Cooper
2017-06-27  6:04   ` Jan Beulich
2017-06-27  7:19     ` Julien Grall
2017-06-27 11:23       ` Jan Beulich
2017-06-27 11:34     ` George Dunlap
2017-06-26 17:00 ` George Dunlap
2017-06-26 17:30   ` Andrew Cooper
2017-06-27  9:17     ` George Dunlap
2017-06-28 16:18       ` Ross Lagerwall
2017-06-28 16:41         ` Konrad Rzeszutek Wilk
2017-06-30 13:42         ` George Dunlap
2017-07-03 14:53           ` Ross Lagerwall
2017-07-04  8:36             ` Roger Pau Monné
2017-08-03 17:20             ` George Dunlap
2017-08-03 17:21               ` George Dunlap
2017-08-06  0:07                 ` Is:livepatch-build-tools.git declare it supported? Was:Re: " Konrad Rzeszutek Wilk
2017-08-07 10:26                   ` George Dunlap
2017-08-07 15:59                     ` Jan Beulich
2017-08-08 11:16                       ` George Dunlap
2017-08-09  7:36                         ` Jan Beulich
2017-08-21 10:59                           ` George Dunlap
2017-08-21 12:07                             ` Jan Beulich
2017-08-21 15:28                               ` George Dunlap
2017-08-22  6:37                                 ` Jan Beulich
2017-08-22 10:58                                   ` George Dunlap
2017-08-22 11:16                                     ` Roger Pau Monné
2017-08-29 14:44                                 ` Konrad Rzeszutek Wilk [this message]
2017-08-29 14:46                                   ` Andrew Cooper
2017-08-29 14:48                                   ` George Dunlap
2017-06-26 18:29 ` Julien Grall
2017-06-26 21:07   ` Konrad Rzeszutek Wilk
2017-06-27  7:24     ` Julien Grall
2017-06-27  8:09       ` Lars Kurth
2017-06-27 10:49         ` Ian Jackson
2017-06-27 10:59           ` Lars Kurth
2017-06-27 10:46       ` Ian Jackson

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20170829144414.GA5224@x230.dumpdata.com \
    --to=konrad.wilk@oracle.com \
    --cc=JBeulich@suse.com \
    --cc=andrew.cooper3@citrix.com \
    --cc=george.dunlap@citrix.com \
    --cc=ian.jackson@eu.citrix.com \
    --cc=julien.grall@arm.com \
    --cc=lars.kurth@citrix.com \
    --cc=liuw@liuw.name \
    --cc=ross.lagerwall@citrix.com \
    --cc=sstabellini@kernel.org \
    --cc=xen-devel@lists.xen.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.