[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 15:22:20 +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=lZQRs8n01FgUcTdtldb14zaD/VwkgPSJCxa4eRxeYXk=; b=ex7DCj1u5B7Lx0v80d0nUQ77SxZJwVZiRxY7IYgGCZsn06CdW9cnEQ+pWoE/i4FDl242pT01kUxEbumUPt5DhCql5iDIFADS7Fi9qw0HtXEJw1M9qci6IlLESK4C1NFQulfNXWZgBwZcuxtL+YqFQa5y2jWX296JHKaAUazwJgiv6hLwq9aTyN4xGEQ8ZD7K/GCMUGxKr96VdEhpHvUXKKFCbkzDtKagJM3kWmG3Q/lbfxiGrhFNfbsMRqYVvMTgAwX65rj+hnoTxTebX3CNwyzwzNkO3TdfdaCTikKsDo4fVqiHH49Qx2BfEAhL/gM6AaFbIJNQ1i5sjoNw0lra+Q==
- Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=CNvgfXVtrjmxdxS5O18YkfP1kh8lIsh/eckW6Q2mS9uvbaxIem2vdxAtVP3cXaaBzS/jSXcObR3Dn3Ysg3O/PfmE66Xp0XplQPFzwaQjtPnqtsOx871Sbc2Y/KbIpsFVfP8HXsyLtrExSSc2atMrmzR9f6eBgjooTL/78zDIPHg4LwdIDp57sJvM0NW7wzF049kyBnfmivZ1ZPZLARcQ35GMEOvtbIucc8tpeywDQkR6hqYlC0YtG3UkhlJZXshf/uqqbui4Nr0jMjrxdiiXNXLK2SpBuxxOHZfqGPHKBaREdtusQbST956pAvvPkFolquHlFCeGP8IdX27Yzy4ufg==
- 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 14:22:55 +0000
- Ironport-data: A9a23:xTjO4qB/c6VUoBVW/+jiw5YqxClBgxIJ4kV8jS/XYbTApGgh0WEAy GdJCz+EOvjYYmPyfNhxbt6+p0gO75bUztNqQQY4rX1jcSlH+JHPbTi7wuUcHAvJd5GeExg3h yk6QoOdRCzhZiaE/n9BCpC48T8nk/nOHuGmYAL9EngZbRd+Tys8gg5Ulec8g4p56fC0GArIs t7pyyHlEAbNNwVcbCRMs8pvlDs15K6p4G1A5ARlDRx2lAS2e0c9Xcp3yZ6ZdxMUcqEMdsamS uDKyq2O/2+x13/B3fv8z94X2mVTKlLjFVDmZkh+AsBOsTAbzsAG6Y4pNeJ0VKtio27hc+ada jl6ncfYpQ8BZsUgkQmGOvVSO3kW0aZuoNcrLZUj2CA6IoKvn3bEmp1T4E8K0YIwo8s0WyZz0 v0hGhNWUgmq3tiS+6C1Rbw57igjBJGD0II3nFhFlGucKMl8BJfJTuPN+MNS2yo2ioZWB/HCa sEFaD1pKhPdfxlIPVRRA5U79AuqriCnL3sE9xTL++xruQA/zyQouFTpGPPTdsaHWoN+mUGAq 3id12/4HgsbJJqUzj/tHneE37aWx32jA9xLfFG+3qFHhWKQ5X42MjQfD127/f/60nSxHM0Kf iT4/QJr98De7neDR93wXRS+rGSD+AAVX95dEeoS4wWK16aS6AGcbkAUQzgEZNE4ucseQT0xy kTPj97vHSZosrCeVTSa7Lj8hTG4NDURLGQCTTQZVgZD6N7myKksijrfQ9AlF7S65uAZAhn1y jGO6S0h3bMaiJdR073hpQydxTWxupLOUwg5oB3NWX6o5R94Y4jjYJG07V/c7rBLK4PxokS9g UXoUvO2tIgmZaxhXgTUKAnRNNlFP8q4DQA=
- Ironport-hdrordr: A9a23:9v5c/aA5WBjKLvzlHelw55DYdb4zR+YMi2TDtnoBMiC9F/byqy nAppomPHPP5Qr5G0tQ/exoQZPgfZqEz/5ICOoqTNWftWvdyROVxehZhOOJ/9SHIVyaygc378 hdmsZFZOEYQmIK6voSTTPIdeoI0Z2syojtr+Hb1nJsRQZhZ+Vb6RtjAArzKDwUeOADP+tBKK ah
- List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
On 01/06/2023 6:43 pm, Alejandro Vallejo wrote:
> 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
> @@ -647,11 +653,18 @@ trampoline_setup:
> cpuid
> 1: mov %edx, CPUINFO_FEATURE_OFFSET(X86_FEATURE_LM) +
> sym_esi(boot_cpu_data)
>
> - /* Check for NX. Adjust EFER setting if available. */
> + /*
> + * Check for NX:
> + * - If Xen was compiled requiring it simply assert it's
> + * supported. The trampoline already has the right constant.
> + * - Otherwise, update the trampoline EFER mask accordingly.
> + */
> bt $cpufeat_bit(X86_FEATURE_NX), %edx
> - jnc 1f
> + jnc no_nx_bit
> +#if !IS_ENABLED(CONFIG_REQUIRE_NX_BIT)
> orb $EFER_NXE >> 8, 1 + sym_esi(trampoline_efer)
> -1:
> +no_nx_bit:
> +#endif
It occurs to me... This will prevent Xen booting in firmware
configurations where XD-Disable is active, despite Xen having
unconditional logic to turn XD off later in boot.
Linux deals with this in verify_cpu() (early asm) along with a FMS check
protecting the access to MSR_MISC_ENABLE, rather than using rdmsr_safe()
and catching the #GP.
In terms of which CPUs are a problem, we almost got very lucky. NX is
part of the AMD64 spec, and all AMD, VIA, Centaur and Intel Atoms have
this property. 64bit and XD were both added midway through the Pentium
4 era, and appear in the Prescott E0 stepping.
However, it appears that the prior stepping, D0, had 64bit but was only
unlocked for certain OEMs. (At the time, Intel were still trying to
push Itaniaum as the future, and were trying hard not to go the x86_64
route.)
Specifically,
https://en.wikipedia.org/wiki/List_of_Intel_Xeon_processors_(NetBurst-based)#%22Nocona%22_(90_nm)
is the suspected problem set.
So, I think this does want to turn into a series, with the first patch
moving the XD-disable logic into this path, after which I think there is
a strong case to be made for defaulting CONFIG_REQUIRE_NX to yes.
~Andrew
|
