[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] x86: Add Kconfig option to require NX bit support


  • To: Alejandro Vallejo <alejandro.vallejo@xxxxxxxxx>, Xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxxx>
  • From: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
  • Date: Fri, 2 Jun 2023 13:05:06 +0100
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=citrix.com; dmarc=pass action=none header.from=citrix.com; dkim=pass header.d=citrix.com; arc=none
  • Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=DglTLmptBa2u8gwTawjsj4jHugysRSZelzptKC/fCvM=; b=CMk3i2HyHeqXLapJTX7rSJHzOZ+7lTDmwQyXXeMkcfVRCFHC8E1LTdEBnK+/KIXvhRuST4z+BdhNraeBI5F0W4kTp16b0MR6njSH8hbubGrSYFXsatt8lFNv577H1D+mL13CTX8xP4IiHrfhgFMQ0s/FUY1Q7GGc0L8DIBLAdvlF06S69s85lqqJZ2e6/RoIR+2LhZgAG7sD1rzqTpmlMQpQzjRiOS0LyAw1eLqYLIH2KnPM0Xuz6qeykEXYShj84JBDedgbREh4/bAdck0Iemyymvmh0RYh5yOzFKnbgW9cfth8Wu1jS4SGedTiAJisiOCx7Dt+Tw7hUJFlY3VdjA==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=oXe+IfKVe41ZZBX7PLUcMNGny3slxOfUR1xYtGkaaHxZFK+JKzelk84aJwAGxUj4bGyFW7+eSfL4sp9sUXT+SmBuO2XuxedYWDplPCR09KYaowt0WN6fDMQM5q1RzZ37jEGw1/SAquDFtZxRm+clfGc+x5KRY/hpitvc6E8lD52+hEWvIxhhGf9woSSb0fXPvtzJzLUDH6qun4MspFXXSFKCrkVPyMAA4WgUII7rzHpk8DkKfK39YgiXNtu7nAVvPrmvnY2+e+PylpsLUxG1PVhXNphOorMsOGshjvtJj26i/CJDAbCaKkJ4LunPo9tvKOnWKB+BEPrkGYuEHtIMOg==
  • Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com;
  • Cc: Jan Beulich <jbeulich@xxxxxxxx>, Roger Pau Monné <roger.pau@xxxxxxxxxx>, Wei Liu <wl@xxxxxxx>
  • Delivery-date: Fri, 02 Jun 2023 12:05:39 +0000
  • Ironport-data: A9a23:/pdS067UV1esl+JMbqKX6wxRtPjGchMFZxGqfqrLsTDasY5as4F+v mFOXTjQb6nZYGv3eIwka43n8k5Tu8PWzIdhTQJrqHxjHi5G8cbLO4+Ufxz6V8+wwm8vb2o8t plDNYOQRCwQZiWBzvt4GuG59RGQ7YnRGvynTraCYnsrLeNdYH9JoQp5nOIkiZJfj9G8Agec0 fv/uMSaM1K+s9JOGjt8B5mr9lU35JwehBtC5gZlPa4T5geH/5UoJMl3yZ+ZfiOQrrZ8RoZWd 86bpJml82XQ+QsaC9/Nut4XpWVTH9Y+lSDX4pZnc/DKbipq/0Te4Y5iXBYoUm9Fii3hojxE4 I4lWapc6+seFvakdOw1C3G0GszlVEFM0OevzXOX6aR/w6BaGpdFLjoH4EweZOUlFuhL7W5my tgJEBNScjS6lsnnnbWJTc1xpMQ5BZy+VG8fkikIITDxK98DGcyGZpqQoNhS0XE3m9xEGuvYa 4wBcz1zYR/cYhpJfFAKFJY5m+TujX76G9FagAvN+exrvC6Ml0ooj+OF3Nn9I7RmQe18mEqCq 32A1GP+GhwAb/SUyCaf82LqjejK9c/+cNtLTeLmp6M32TV/wERQCgRNFl3jm8O80HCmQvVGL 09E9iox+P1aGEuDC4OVsweDiHeAsxwVXdZKFKsk4QWJx6jTyw2dAXUICDVGbbQOpMIwADAny FKNt9foHiB09q2YT2qH8bWZpi/0PjIaRUcAbyIZSQoO4/H4vZo+yBnIS75LD6qdntDzXzbqz Fi3QDMWgrwSiYsOyP+99FWf3za0/MGWFUgy+xndWX+j4kVhfom5aoe06F/dq/FdMIKeSVrHt 38B8ySD0N0z4Vi2vHTlaI0w8HuBvp5p7BW0bYZTIqQc
  • Ironport-hdrordr: A9a23:akYXw67cKMJh6z8YMAPXwAzXdLJyesId70hD6qkQc3Fom62j5q WTdZEgvyMc5wx/ZJhNo7690cq7MBHhHPxOgbX5VI3KNGXbUQOTR72KhrGSoAEIdReeygZcv5 0QCZSXCrfLfCVHZRCR2njFLz4iquP3j5xBnY3lvhNQpZkBUdAZ0+9+YDzrdXFedU19KrcSMo GT3cZDryrIQwVtUizqbkN1OdQqvrfw5evbXSI=
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On 01/06/2023 6:43 pm, Alejandro Vallejo wrote:
> This allows replacing many instances of runtime checks with folded
> constants. The patch asserts support for the NX bit in PTEs at boot time
> and if so short-circuits cpu_has_nx to 1. This has several knock-on effects
> that improve codegen:
>   * _PAGE_NX matches _PAGE_NX_BIT, optimising the macro to a constant.
>   * Many PAGE_HYPERVISOR_X are also folded into constants
>   * A few if ( cpu_has_nx ) statements are optimised out
>
> We save 2.5KiB off the text section and remove the runtime dependency for
> applying NX, which hardens our security posture. The config option defaults
> to OFF for compatibility with previous behaviour.

While this is all true, I'd say it's not emphasising the correct point.

Right now, any attacker with a partial write primitive who can clear the
NX feature bit in boot_cpu_info will cause Xen to unintentionally write
insecure PTEs.  (Or for that matter, a memory corruption bug in Xen.)

NX exists on all 64bit CPUs other than early Pentium 4's, and people who
don't care about those CPUs can meaningfully improve their security
defence-in-depth by enabling this option.

The fact we also save 2.5k of code is a nice bonus, but not relevant. 
People aren't going to turn this option on to save code - they're going
to turn it on for the extra security.  It's fine to mention, but the
code gen improvements should be one sentence max, not the majority of
the commit message.

> Signed-off-by: Alejandro Vallejo <alejandro.vallejo@xxxxxxxxx>
> ---
>  xen/arch/x86/Kconfig                  | 10 ++++++++++
>  xen/arch/x86/boot/head.S              | 19 ++++++++++++++++---
>  xen/arch/x86/boot/trampoline.S        |  3 ++-
>  xen/arch/x86/efi/efi-boot.h           |  9 +++++++++
>  xen/arch/x86/include/asm/cpufeature.h |  3 ++-
>  5 files changed, 39 insertions(+), 5 deletions(-)
>
> diff --git a/xen/arch/x86/Kconfig b/xen/arch/x86/Kconfig
> index 406445a358..0983915372 100644
> --- a/xen/arch/x86/Kconfig
> +++ b/xen/arch/x86/Kconfig
> @@ -307,6 +307,16 @@ config MEM_SHARING
>       bool "Xen memory sharing support (UNSUPPORTED)" if UNSUPPORTED
>       depends on HVM
>  
> +config REQUIRE_NX_BIT
> +     def_bool n
> +     prompt "Require NX bit support"
> +     ---help---
> +       Makes Xen require NX bit support on page table entries. This
> +       allows the resulting code to have folded constants where
> +       otherwise branches are required, yielding a smaller binary as a
> +       result. Requiring NX trades compatibility with older CPUs for
> +       improvements in speed and code size.

The intended audience here is different.  x86 developers will know what
this means from the name alone, and won't read the help.  It's distro
packagers and end users who need to be able to read this and decide
whether to turn it on or not.  Therefore, it needs to read something
more like this:

No-eXecute (also called XD "eXecute Disable" and DEP "Data Execution
Prevention") is a security feature designed originally to combat buffer
overflow attacks by marking regions of memory which the CPU must not
interpret as instructions.

The NX feature exists in almost 64bit capable CPUs, except XXX [TBC - we
might be extremely lucky here.  Questions pending with people].

Enabling this option will improve Xen's security by removing cases where
Xen could be tricked into thinking that the feature was unavailable. 
However, if enabled, Xen will no longer boot on any CPU which is lacking
NX support.

> +
>  endmenu
>  
>  source "common/Kconfig"
> diff --git a/xen/arch/x86/boot/head.S b/xen/arch/x86/boot/head.S
> index 09bebf8635..8414266281 100644
> --- a/xen/arch/x86/boot/head.S
> +++ b/xen/arch/x86/boot/head.S
> @@ -123,6 +123,7 @@ multiboot2_header:
>  .Lbad_ldr_nih: .asciz "ERR: EFI ImageHandle is not provided by bootloader!"
>  .Lbad_efi_msg: .asciz "ERR: EFI IA-32 platforms are not supported!"
>  .Lbag_alg_msg: .asciz "ERR: Xen must be loaded at a 2Mb boundary!"
> +.Lno_nx_bit_msg: .asciz "ERR: Not an NX-bit capable CPU!"
>  
>          .section .init.data, "aw", @progbits
>          .align 4
> @@ -151,6 +152,11 @@ not_multiboot:
>  .Lnot_aligned:
>          add     $sym_offs(.Lbag_alg_msg),%esi   # Error message
>          jmp     .Lget_vtb
> +#if IS_ENABLED(CONFIG_REQUIRE_NX_BIT)

This doesn't need to be IS_ENABLED().  #if will DTRT for a non-existent
symbol by considering such to be 0.

IS_ENABLED() is only required for cases where you need an explicit 0 or
1 at the end, which is typically only in real C code, and for
initialising of constants.

> +no_nx_bit:
> +        add     $sym_offs(.Lno_nx_bit_msg),%esi   # Error message

The "# Error message" is useless as a comment.  Don't propagate it from
the other bad examples.

(I already had some cleanup planned here from Roger's patch adding
not_aligned.)

~Andrew



 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.