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

Re: [PATCH v2 1/2] x86/boot: Clear XD_DISABLE from the early boot path


  • To: Alejandro Vallejo <alejandro.vallejo@xxxxxxxxx>
  • From: Jan Beulich <jbeulich@xxxxxxxx>
  • Date: Fri, 23 Jun 2023 08:49:42 +0200
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=suse.com; dmarc=pass action=none header.from=suse.com; dkim=pass header.d=suse.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=5XGLN7Byf0hb8mpSTC/rlelxmIgsWi0ZmRrqAC72Fno=; b=T/BA0kZTq1wKQ0EqiCfpFY9ff4fR9QKNKlcuYPKwchXRowPhGp1waskfFSPX/V1vB8rP3BsWdmTO9iTBReZOfxR7Iy4LR2OIexb1Yt7UWDeKJawW8C9R+sDDo68k7vaNySQx1jErpWXE4acSQl96TZOdaMdHEV1Vw7fIfeDgA//0T84YtbtBS9hHWBScT4UdrAcpYcpRRebBSmngv/ASXW4/cAfzpx+p5fZfaM+FIWf00A/pOAO8u29/hbNrLCxMFZ/fuz12X8SOoPF5vWoizhLmrtSgGzABAm0NTG1TUlPMHJmxKQ0VHdK5b7pt2coz+/UfmGM+bx10QNQtlpdLqw==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=ULKM2Hd9uYqqXheoE++k4UtR3Gf31YDSR+1jZncDT/RVhM0Ra6/1nrGG+9kJp+uSKCC6RsHf7/CI81R+tYy/6xduX3lcW2m/odp8S53nqDT8hs8P/wsGtuoy7tAYUm8ZPVSB+WoUTgmP/HJYgVfWIuxK6qR2zTcpK+SOnsbr5lFnotkB/uATlNZ3we3nhojsMDLJfBKqzjiB8Zc4N0TWLz9oTvNjU3QF7iMSt3hR48Af/17rMr09ruUm1VMfpXUqpk7aF/B0ivmy/fJWh8hqU/gjvwoQAq2+cVJpRZJW3azX740gexvhwXyh+v0EcdTjalDBsxKIG57upkIa9MS/3w==
  • Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=suse.com;
  • Cc: Xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxxx>, Roger Pau Monné <roger.pau@xxxxxxxxxx>, Wei Liu <wl@xxxxxxx>, Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
  • Delivery-date: Fri, 23 Jun 2023 06:50:08 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On 22.06.2023 17:49, Alejandro Vallejo wrote:
> On Thu, Jun 22, 2023 at 09:54:01AM +0200, Jan Beulich wrote:
>> On 21.06.2023 18:43, Alejandro Vallejo wrote:
>>> Sure, to everything before this
>>>
>>>>> diff --git a/xen/arch/x86/cpu/intel.c b/xen/arch/x86/cpu/intel.c
>>>>> index 168cd58f36..46b0cd8dbb 100644
>>>>> --- a/xen/arch/x86/cpu/intel.c
>>>>> +++ b/xen/arch/x86/cpu/intel.c
>>>>> @@ -305,23 +305,23 @@ static void cf_check early_init_intel(struct 
>>>>> cpuinfo_x86 *c)
>>>>>           c->x86_cache_alignment = 128;
>>>>>  
>>>>>   /* Unmask CPUID levels and NX if masked: */
>>>>> - rdmsrl(MSR_IA32_MISC_ENABLE, misc_enable);
>>>>> -
>>>>> - disable = misc_enable & (MSR_IA32_MISC_ENABLE_LIMIT_CPUID |
>>>>> -                          MSR_IA32_MISC_ENABLE_XD_DISABLE);
>>>>> - if (disable) {
>>>>> -         wrmsrl(MSR_IA32_MISC_ENABLE, misc_enable & ~disable);
>>>>> -         bootsym(trampoline_misc_enable_off) |= disable;
>>>>> -         bootsym(trampoline_efer) |= EFER_NXE;
>>>>> - }
>>>>> + if (rdmsr_safe(MSR_IA32_MISC_ENABLE, misc_enable) == 0) {
>>>>
>>>> There's no need to change rdmsrl() to rdmsr_safe(),
>>> I thought we established before some hypervisors might not implement it. In
>>> that case this function would crash. More gracefully than a triple fault,
>>> sure, but still not a very friendly thing to do.
>>
>> Yet then in early boot code you also don't (and can't) recover from getting
>> #GP(0), in case that might really happen.
>>
> That's true, strictly speaking, but that case is restricted to the
> incredibly unlikely case of "no NX and no MSR". As is, if we ever boot
> on an Intel machine without that MSR we'll hit #GP(0), regardless of NX.

Well, my comment was meant to support Andrew's earlier one. Why
check the MSR access here when we don't earlier on? Plus isn't
it the case that the MSR can be implied to exist when NX is (in
principle) available, as that "opt-out" existed specifically
when Intel first introduced NX on their CPUs? If so,
- when NX is not available, we would have crashed much earlier,
- when NX is available (or was turned on successfully) the MSR
  exists either because we wrote to it earlier or because we're
  on a newer CPU.

Jan



 


Rackspace

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