public inbox for devel@edk2.groups.io
 help / color / mirror / Atom feed
From: Laszlo Ersek <lersek@redhat.com>
To: "Wang, Jian J" <jian.j.wang@intel.com>,
	"edk2-devel@lists.01.org" <edk2-devel@lists.01.org>
Cc: "Ni, Ruiyu" <ruiyu.ni@intel.com>,
	"Yao, Jiewen" <jiewen.yao@intel.com>,
	"Dong, Eric" <eric.dong@intel.com>
Subject: Re: [PATCH 1/6] UefiCpuPkg/MpInitLib: split wake up buffer into two parts
Date: Mon, 29 Jan 2018 16:50:43 +0100	[thread overview]
Message-ID: <8a904ec0-b879-aa17-ac52-f928b0c5c18f@redhat.com> (raw)
In-Reply-To: <D827630B58408649ACB04F44C510003624CDF8DD@SHSMSX103.ccr.corp.intel.com>

On 01/29/18 02:06, Wang, Jian J wrote:
> Hi Laszlo,
> 
> We've found this issue. The patch for it has sent out at 
> 
> https://lists.01.org/pipermail/edk2-devel/2018-January/020467.html 
> 
> It will be checked in soon.

I've rebuilt OVMF @ c4122dcaadb9 ("SecurityPkg: Tcg2Smm: Enable TPM2.0
interrupt support", 2018-01-29) and indeed it works fine. Thank you!

Laszlo


>> -----Original Message-----
>> From: Laszlo Ersek [mailto:lersek@redhat.com]
>> Sent: Monday, January 29, 2018 5:44 AM
>> To: Wang, Jian J <jian.j.wang@intel.com>; edk2-devel@lists.01.org
>> Cc: Ni, Ruiyu <ruiyu.ni@intel.com>; Yao, Jiewen <jiewen.yao@intel.com>; Dong,
>> Eric <eric.dong@intel.com>
>> Subject: Re: [edk2] [PATCH 1/6] UefiCpuPkg/MpInitLib: split wake up buffer into
>> two parts
>>
>> On 01/27/18 17:17, Laszlo Ersek wrote:
>>> Hello Jian,
>>>
>>> On 01/15/18 09:54, Jian J Wang wrote:
>>>> If PcdDxeNxMemoryProtectionPolicy is set to enable protection for memory
>>>> of EfiBootServicesCode, EfiConventionalMemory, the BIOS will hang at a
>> page
>>>> fault exception during MP initialization.
>>>>
>>>> The root cause is that the AP wake up buffer, which is below 1MB and used
>>>> to hold both AP init code and data, is type of EfiConventionalMemory (not
>>>> really allocated because of potential conflict with legacy code), and is
>>>> marked as non-executable. During the transition from real address mode
>>>> to long mode, the AP init code has to enable paging which will then cause
>>>> itself a page fault exception because it's just running in non-executable
>>>> memory.
>>>>
>>>> The solution is splitting AP wake up buffer into two part: lower part is
>>>> still below 1MB and shared with legacy system, higher part is really
>>>> allocated memory of BootServicesCode type. The init code in the memory
>>>> below 1MB will not enable paging but just switch to protected mode and
>>>> jump to higher memory, in which the init code will enable paging and
>>>> switch to long mode.
>>>>
>>>> Cc: Jiewen Yao <jiewen.yao@intel.com>
>>>> Cc: Ruiyu Ni <ruiyu.ni@intel.com>
>>>> Cc: Eric Dong <eric.dong@intel.com>
>>>> Cc: Laszlo Ersek <lersek@redhat.com>
>>>> Contributed-under: TianoCore Contribution Agreement 1.1
>>>> Signed-off-by: Jian J Wang <jian.j.wang@intel.com>
>>>> ---
>>>>  UefiCpuPkg/Library/MpInitLib/DxeMpLib.c        | 34 ++++++++++
>>>>  UefiCpuPkg/Library/MpInitLib/Ia32/MpEqu.inc    |  5 ++
>>>>  UefiCpuPkg/Library/MpInitLib/Ia32/MpFuncs.nasm | 32 +++++-----
>>>>  UefiCpuPkg/Library/MpInitLib/MpLib.c           | 45 +++++++++++++
>>>>  UefiCpuPkg/Library/MpInitLib/MpLib.h           | 22 +++++++
>>>>  UefiCpuPkg/Library/MpInitLib/PeiMpLib.c        | 23 +++++++
>>>>  UefiCpuPkg/Library/MpInitLib/X64/MpEqu.inc     |  5 +-
>>>>  UefiCpuPkg/Library/MpInitLib/X64/MpFuncs.nasm  | 87 ++++++++++++++++-
>> ---------
>>>>  8 files changed, 204 insertions(+), 49 deletions(-)
>>>
>>> This patch breaks OVMF on KVM. The symptom is that the guest crashes
>>> and reboots as follows (infinite reboot loop):
>>>
>>>> Loading PEIM at 0x0007FEB0000 EntryPoint=0x0007FEB5C96 CpuMpPei.efi
>>>> AP Loop Mode is 1
>>>> WakeupBufferStart = 9F000, WakeupBufferSize = 1000
>>>> -- crash & reboot here --
>>>> SecCoreStartupWithStack(0xFFFCC000, 0x820000)
>>
>> The following build options were used for this build:
>>
>> $ build -a X64 -p OvmfPkg/OvmfPkgX64.dsc -D SECURE_BOOT_ENABLE \
>>     -t GCC48 -b NOOPT -D HTTP_BOOT_ENABLE
>>
>> The tree was built at 06c1f423e17f ("BeagleBoardPkg: reroute Firmware
>> Vendor Pcd to MdeModulePkg", 2018-01-26). (This commit is listed at the
>> top of the bisection log in my previous email.)
>>
>> Here's the KVM log up to the triple fault:
>>
>>>              CPU-32283 [004] 13652.374591: kvm_entry:            vcpu 2
>>>              CPU-32283 [004] 13652.374594: kvm_exit:             reason CR_ACCESS
>> rip 0x3a info 0 0
>>>              CPU-32283 [004] 13652.374595: kvm_cr:               cr_write 0 =
>> 0x60000013
>>>              CPU-32283 [004] 13652.374596: kvm_entry:            vcpu 2
>>>              CPU-32283 [004] 13652.374597: kvm_exit:             reason CR_ACCESS
>> rip 0x9f06a info 4 0
>>>              CPU-32283 [004] 13652.374598: kvm_cr:               cr_write 4 = 0x20
>>>              CPU-32283 [004] 13652.374603: kvm_entry:            vcpu 2
>>>              CPU-32283 [004] 13652.374604: kvm_exit:             reason CR_ACCESS
>> rip 0x9f075 info 103 0
>>>              CPU-32283 [004] 13652.374605: kvm_cr:               cr_write 3 = 0x800000
>>>              CPU-32283 [004] 13652.374606: kvm_entry:            vcpu 2
>>>              CPU-32283 [004] 13652.374607: kvm_exit:             reason MSR_READ
>> rip 0x9f07d info 0 0
>>>              CPU-32283 [004] 13652.374608: kvm_msr:              msr_read c0000080
>> = 0x0
>>>              CPU-32283 [004] 13652.374608: kvm_entry:            vcpu 2
>>>              CPU-32283 [004] 13652.374609: kvm_exit:             reason MSR_WRITE
>> rip 0x9f083 info 0 0
>>>              CPU-32283 [004] 13652.374611: kvm_msr:              msr_write c0000080
>> = 0x100
>>>              CPU-32283 [004] 13652.374612: kvm_entry:            vcpu 2
>>>              CPU-32283 [004] 13652.374613: kvm_exit:             reason CR_ACCESS
>> rip 0x9f08c info 0 0
>>>              CPU-32283 [004] 13652.374613: kvm_cr:               cr_write 0 =
>> 0xe0000013
>>>              CPU-32283 [004] 13652.374620: kvm_entry:            vcpu 2
>>>              CPU-32283 [004] 13652.374622: kvm_exit:             reason
>> TRIPLE_FAULT rip 0x9f096 info 0 0
>>
>> Offset 0x96 (relative to 0x9F000) is from
>> "UefiCpuPkg/Library/MpInitLib/X64/MpFuncs.nasm":
>>
>>> 5c66d125eaae5 (Jeff Fan       2016-07-29 21:13:34 +0800 103)
>> SkipEnableExecuteDisableBit:
>>> f32bfe6d06142 (Jian J Wang    2017-12-29 09:12:54 +0800 104)     ;
>>> f32bfe6d06142 (Jian J Wang    2017-12-29 09:12:54 +0800 105)     ; Enable PAE
>>> f32bfe6d06142 (Jian J Wang    2017-12-29 09:12:54 +0800 106)     ;
>>> d94e5f672994f (Jeff Fan       2016-07-20 22:44:39 +0800 107)     mov        eax,
>> cr4
>>> d94e5f672994f (Jeff Fan       2016-07-20 22:44:39 +0800 108)     bts        eax, 5
>>> d94e5f672994f (Jeff Fan       2016-07-20 22:44:39 +0800 109)     mov        cr4,
>> eax
>>> d94e5f672994f (Jeff Fan       2016-07-20 22:44:39 +0800 110)
>>> f32bfe6d06142 (Jian J Wang    2017-12-29 09:12:54 +0800 111)     ;
>>> f32bfe6d06142 (Jian J Wang    2017-12-29 09:12:54 +0800 112)     ; Load page
>> table
>>> f32bfe6d06142 (Jian J Wang    2017-12-29 09:12:54 +0800 113)     ;
>>> f32bfe6d06142 (Jian J Wang    2017-12-29 09:12:54 +0800 114)     mov        esi,
>> Cr3Location             ; Save CR3 in ecx
>>> f32bfe6d06142 (Jian J Wang    2017-12-29 09:12:54 +0800 115)     mov        ecx,
>> [ebx + esi]
>>> d94e5f672994f (Jeff Fan       2016-07-20 22:44:39 +0800 116)     mov        cr3,
>> ecx                    ; Load CR3
>>> d94e5f672994f (Jeff Fan       2016-07-20 22:44:39 +0800 117)
>>> f32bfe6d06142 (Jian J Wang    2017-12-29 09:12:54 +0800 118)     ;
>>> f32bfe6d06142 (Jian J Wang    2017-12-29 09:12:54 +0800 119)     ; Enable long
>> mode
>>> f32bfe6d06142 (Jian J Wang    2017-12-29 09:12:54 +0800 120)     ;
>>> d94e5f672994f (Jeff Fan       2016-07-20 22:44:39 +0800 121)     mov        ecx,
>> 0c0000080h             ; EFER MSR number
>>> d94e5f672994f (Jeff Fan       2016-07-20 22:44:39 +0800 122)
>> rdmsr                                  ; Read EFER
>>> d94e5f672994f (Jeff Fan       2016-07-20 22:44:39 +0800 123)     bts        eax,
>> 8                      ; Set LME=1
>>> d94e5f672994f (Jeff Fan       2016-07-20 22:44:39 +0800 124)
>> wrmsr                                  ; Write EFER
>>> d94e5f672994f (Jeff Fan       2016-07-20 22:44:39 +0800 125)
>>> f32bfe6d06142 (Jian J Wang    2017-12-29 09:12:54 +0800 126)     ;
>>> f32bfe6d06142 (Jian J Wang    2017-12-29 09:12:54 +0800 127)     ; Enable
>> paging
>>> f32bfe6d06142 (Jian J Wang    2017-12-29 09:12:54 +0800 128)     ;
>>> d94e5f672994f (Jeff Fan       2016-07-20 22:44:39 +0800 129)     mov        eax,
>> cr0                    ; Read CR0
>>> d94e5f672994f (Jeff Fan       2016-07-20 22:44:39 +0800 130)     bts        eax,
>> 31                     ; Set PG=1
>>> d94e5f672994f (Jeff Fan       2016-07-20 22:44:39 +0800 131)     mov        cr0,
>> eax                    ; Write CR0
>>> d94e5f672994f (Jeff Fan       2016-07-20 22:44:39 +0800 132)
>>> f32bfe6d06142 (Jian J Wang    2017-12-29 09:12:54 +0800 133)     ;
>>> f32bfe6d06142 (Jian J Wang    2017-12-29 09:12:54 +0800 134)     ; Far jump to
>> 64-bit code
>>> f32bfe6d06142 (Jian J Wang    2017-12-29 09:12:54 +0800 135)     ;
>>> f32bfe6d06142 (Jian J Wang    2017-12-29 09:12:54 +0800 136)     mov        edi,
>> ModeHighMemoryLocation
>>> f32bfe6d06142 (Jian J Wang    2017-12-29 09:12:54 +0800 137)     add        edi,
>> ebx
>>> f32bfe6d06142 (Jian J Wang    2017-12-29 09:12:54 +0800 138)     jmp far    [edi]
>> <- here
>>
>> Thanks
>> Laszlo
> _______________________________________________
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel
> 



  reply	other threads:[~2018-01-29 15:45 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-01-15  8:54 [PATCH 0/6] Fix issues caused by NX memory protection Jian J Wang
2018-01-15  8:54 ` [PATCH 1/6] UefiCpuPkg/MpInitLib: split wake up buffer into two parts Jian J Wang
2018-01-18  6:53   ` Dong, Eric
2018-01-27 16:17   ` Laszlo Ersek
2018-01-28 21:43     ` Laszlo Ersek
2018-01-29  1:06       ` Wang, Jian J
2018-01-29 15:50         ` Laszlo Ersek [this message]
2018-01-15  8:54 ` [PATCH 2/6] UefiCpuPkg/CpuExceptionHandlerLib: alloc code memory for exception handlers Jian J Wang
2018-01-16 14:02   ` Dong, Eric
2018-01-15  8:54 ` [PATCH 3/6] UefiCpuPkg/CpuDxe: clear NX attr for page directory Jian J Wang
2018-01-16 14:02   ` Dong, Eric
2018-01-15  8:54 ` [PATCH 4/6] UefiCpuPkg/PiSmmCpuDxeSmm: Enable NXE if it's supported Jian J Wang
2018-01-16 14:02   ` Dong, Eric
2018-01-28 22:46   ` Laszlo Ersek
2018-01-29  9:02     ` Wang, Jian J
2018-01-29 19:48       ` Laszlo Ersek
2018-01-30 13:09         ` Laszlo Ersek
2018-02-01  1:08         ` Wang, Jian J
2018-01-15  8:54 ` [PATCH 5/6] MdeModulePkg/PiSmmCore: remove NX attr for SMM RAM Jian J Wang
2018-01-15 10:18   ` Zeng, Star
2018-01-15  8:54 ` [PATCH 6/6] MdeModulePkg/BootScriptExecutorDxe: remove NX attr for FfsBuffer Jian J Wang
2018-01-15 10:18   ` Zeng, Star

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-list 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=8a904ec0-b879-aa17-ac52-f928b0c5c18f@redhat.com \
    --to=devel@edk2.groups.io \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox