From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrew Cooper Subject: Re: [PATCH] x86: wrap kexec feature with CONFIG_KEXEC Date: Tue, 1 Sep 2015 11:44:01 +0100 Message-ID: <55E58171.80509@citrix.com> References: <1440686870-19104-1-git-send-email-jonathan.creekmore@gmail.com> <55DF2C57.8030100@citrix.com> <1441103777.27618.31.camel@citrix.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZWj33-0005F7-J7 for xen-devel@lists.xenproject.org; Tue, 01 Sep 2015 10:44:17 +0000 In-Reply-To: <1441103777.27618.31.camel@citrix.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Ian Campbell , Jonathan Creekmore , David Vrabel Cc: xen-devel@lists.xenproject.org, keir@xen.org, jbeulich@suse.com List-Id: xen-devel@lists.xenproject.org On 01/09/15 11:36, Ian Campbell wrote: > On Thu, 2015-08-27 at 10:44 -0500, Jonathan Creekmore wrote: >>> On Aug 27, 2015, at 10:27 AM, David Vrabel >>> wrote: >>> >>> On 27/08/15 15:47, Jonathan Creekmore wrote: >>>> Add the appropriate #if checks around the kexec code in the x86 >>>> codebase >>>> so that the feature can actually be turned off by the flag instead of >>>> always required to be enabled on x86. >>> What's your use case for this? >>> >> The use case is for a slimmed down version of the hypervisor that can be >> used as a security hypervisor, exposing as little extra functionality as >> possible. When looking for features to trim out to reduce the attack >> surface, I saw the flag for KEXEC and wanted to disable that, then ran >> into compile problems. > Can this not be achieved at runtime with XSM? Doing so would be contrary to the intent of reducing the attack surface. > > In general (i.e. not 100% consistently, I think) we have tended to avoid > making things user-facing compile time options. Many of the existing > CONFIG_* and HAVE_* are really about things which are arch dependent, or > require specific porting to each arch etc. I think the KEXEC flag is one of > those. > > This keeps the test matrix more reasonable (unlike e.g. Linux's Kconfig) > and also helps us by ensuring that users are mostly running one of a small > number of possible configs. > > I slightly fear that after Kexec you are going to want to strip out more > and more stuff... I for one welcome a Kconfig style approach. We will never be in the same order of magnitude of options as Linux, and it will help to properly modularise the code. ~Andrew