From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id 1022881D34 for ; Fri, 4 Nov 2016 08:22:03 -0700 (PDT) Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 90FC9ABB00; Fri, 4 Nov 2016 15:22:04 +0000 (UTC) Received: from lacos-laptop-7.usersys.redhat.com (ovpn-116-156.phx2.redhat.com [10.3.116.156]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id uA4FM179024982; Fri, 4 Nov 2016 11:22:01 -0400 To: "Yao, Jiewen" References: <1478156028-21572-1-git-send-email-jiewen.yao@intel.com> <74D8A39837DF1E4DA445A8C0B3885C50386BDEF5@shsmsx102.ccr.corp.intel.com> Cc: "Tian, Feng" , =?UTF-8?B?UmFkaW0gS3I/bcOhPw==?= , "edk2-devel@ml01.01.org" , "Kinney, Michael D" , Paolo Bonzini , "Fan, Jeff" , "Zeng, Star" From: Laszlo Ersek Message-ID: Date: Fri, 4 Nov 2016 16:22:00 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <74D8A39837DF1E4DA445A8C0B3885C50386BDEF5@shsmsx102.ccr.corp.intel.com> X-Scanned-By: MIMEDefang 2.68 on 10.5.11.24 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.25]); Fri, 04 Nov 2016 15:22:04 +0000 (UTC) Subject: Re: [PATCH 0/6] Enable SMM page level protection. X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Nov 2016 15:22:03 -0000 Content-Type: text/plain; charset=iso-8859-2 Content-Transfer-Encoding: 8bit On 11/04/16 00:51, Yao, Jiewen wrote: > Hi Laszlo > I appreciate your help to validate the patch for me. Well, part of me is just plain altruistic :), but another part of me is responsible for OVMF at Red Hat, and I'd rather find out about any possible regressions before they are committed ;) > Yes, I am using a windows QEMU binary. (qemu-system-x86_64.exe) > > A quick look at the code. > > > 1) The ASSERT issue >> ASSERT UefiCpuPkg/PiSmmCpuDxeSmm/SmmCpuMemoryManagement.c(468): !EFI_ERROR (Status) > is caused by this line: > Status = SmmBlockingStartupThisAp (FlushTlbOnCurrentProcessor, Index, NULL); > ASSERT_EFI_ERROR(Status); > > I am surprise to see it, because I think is an impossible case - InternalSmmStartupThisAp(). > if (CpuIndex >= gSmmCpuPrivate->SmmCoreEntryContext.NumberOfCpus || > CpuIndex == gSmmCpuPrivate->SmmCoreEntryContext.CurrentlyExecutingCpu || > !(*(mSmmMpSyncData->CpuData[CpuIndex].Present)) || > gSmmCpuPrivate->Operation[CpuIndex] == SmmCpuRemove) { > return EFI_INVALID_PARAMETER; > } > > I am using below line to start QEMU: > "qemu-system-x86_64.exe -machine q35,smm=on,accel=tcg -smp 1 -drive if=pflash,format=raw,unit=0,file=OVMF_CODE.fd,readonly=on -drive if=pflash,format=raw,unit=1,file=OVMF_VARS.fd --serial COM8 -boot menu=on,splash-time=7000 fat:rw:Test" > > Would you mind let me know what is difference between your environment and mine? > > I will add more debug info to see what happened, which of above lines triggers the error. (I will comment on this elsewhere.) > 2) The unstable case is a headache. > According to "RIP=000000000009f0fd", it seems outside of SMM right? So, this address can be correlated with the final part of the OVMF debug log. The OVMF debug log says (as I wrote), > Transfer to 16bit OS waking vector - 9A1D0 and the RIP in the failure info is 9f0fd -- the difference is just 0x4F2D (20269) bytes. So, I must think, something blows up in the resume vector of the Linux kernel that I used as guest for testing. (Also, you can confirm we are outside of SMM from the string "SMM=0" in the register dump.) > What does this *KVM internal error. Suberror: 1* mean? The key message is "emulation failure" -- it means that the processor exits to the hypervisor (KVM) because it finds some code that it cannot execute in guest mode natively, so the hypervisor needs to emulate it. And, this emulation fails. The reasons can be: - the code is valid, but KVM lacks the emulation code for it, - the code is actually garbage (not code) -- there was some corruption in the guest (the location used to contain code but it was corrupted, or the guest jumped to non-code data). Usually the register dump contains a short hexadecimal snippet from the instruction stream (near Code=...), pinpointing the byte that caused the problem. However, in this case, all we have is question marks, and this is the very first time I see those. That's why I CC'd Paolo and Radim :) Thanks Laszlo > > Do you have any clue on what happened? > > Thank you > Yao Jiewen > > From: edk2-devel [mailto:edk2-devel-bounces@lists.01.org] On Behalf Of Laszlo Ersek > Sent: Friday, November 4, 2016 5:43 AM > To: Yao, Jiewen > Cc: Tian, Feng ; Radim Krèmáø ; edk2-devel@ml01.01.org; Kinney, Michael D ; Paolo Bonzini ; Fan, Jeff ; Zeng, Star > Subject: Re: [edk2] [PATCH 0/6] Enable SMM page level protection. > > On 11/03/16 07:53, Jiewen Yao wrote: >> This series patch enables SMM page level protection. >> Features are: >> 1) PiSmmCore reports SMM PE image code/data information >> in EdkiiPiSmmMemoryAttributeTable, if the SMM image is page aligned. >> 2) PiSmmCpu consumes EdkiiPiSmmMemoryAttributeTable >> and set XD for data page and RO for code page. >> 3) PiSmmCpu enables Static Paging for X64 according to >> PcdCpuSmmStaticPageTable. If it is true, 1G paging for above 4G >> is used as long as it is supported. >> 4) PiSmmCpu sets importance data structure to be read only, >> such as Gdt, Idt, SmmEntrypoint, and PageTable itself. >> >> tested platform: >> 1) Intel internal platform (X64). >> 2) EDKII Quark IA32 >> 3) EDKII Vlv2 X64 >> 4) EDKII OVMF IA32 and IA32X64. > > Did you use a Windows QEMU binary for the OVMF tests? > > Please find my test results below, all done on KVM > (3.10.0-514.el7.x86_64, if anyone is curious :)). > >> >> Cc: Jeff Fan > >> Cc: Feng Tian > >> Cc: Star Zeng > >> Cc: Michael D Kinney > >> Cc: Laszlo Ersek > >> Contributed-under: TianoCore Contribution Agreement 1.0 >> Signed-off-by: Jiewen Yao > >> >> Jiewen Yao (6): >> MdeModulePkg/Include: Add PiSmmMemoryAttributesTable.h >> MdeModulePkg/dec: Add gEdkiiPiSmmMemoryAttributesTableGuid. >> MdeModulePkg/PiSmmCore: Add MemoryAttributes support. >> UefiCpuPkg/dec: Add PcdCpuSmmStaticPageTable. >> UefiCpuPkg/PiSmmCpuDxeSmm: Add paging protection. >> QuarkPlatformPkg/dsc: enable Smm paging protection. > > Legend: > > - "untested" means the test was not executed because the same test > failed or proved unreliable in a less demanding configuration already, > > - "n/a" means a setting or test case was impossible, > > - "fail" and "unreliable" (lower case) are outside the scope of this > series; they either capture the pre-series status, or are expected > even with the series applied due to the pre-series status, > > - "FAIL" and "UNRELIABLE" mean regressions caused (or exposed) by the > series. > > In all cases, 36 bits were used as address width in the CPU HOB (--> up > to 64GB guest-phys address space). > > series OVMF VCPU boot S3 resume > # applied platform PcdCpuMaxLogicalProcessorNumber PcdCpuSmmStaticPageTable topology result result > -- ------- -------- ------------------------------- ------------------------ -------- ------ --------- > 1 no Ia32 64 n/a 1x2x2 pass unreliable > 2 no Ia32 255 n/a 52x2x2 pass untested > 3 no Ia32 255 n/a 53x2x2 unreliable untested > 4 no Ia32X64 64 n/a 1x2x2 pass pass > 5 no Ia32X64 255 n/a 52x2x2 pass pass > 6 no Ia32X64 255 n/a 54x2x2 fail n/a > 7 yes Ia32 64 FALSE 1x2x2 FAIL n/a > 8 yes Ia32 64 TRUE 1x2x2 FAIL n/a > 9 yes Ia32 255 FALSE 52x2x2 untested untested > 10 yes Ia32 255 FALSE 53x2x2 untested untested > 11 yes Ia32 255 TRUE 52x2x2 untested untested > 12 yes Ia32 255 TRUE 53x2x2 untested untested > 13 yes Ia32X64 64 FALSE 1x2x2 pass UNRELIABLE > 14 yes Ia32X64 64 TRUE 1x2x2 FAIL n/a > 15 yes Ia32X64 255 FALSE 52x2x2 pass untested > 16 yes Ia32X64 255 FALSE 54x2x2 fail untested > 17 yes Ia32X64 255 TRUE 52x2x2 untested untested > 18 yes Ia32X64 255 TRUE 54x2x2 untested untested > > Notes for the baseline tests (1-6): > > * test 3: boot unreliable due to out-of-SMRAM (depends on what we do > during boot) > > * test 5: S3 wakeup: 1 try, suspend takes very long, CPU intensive; > wakeup is quick, works okay > > * test 6: boot fail: out of SMRAM (expected) > > Notes for the tests with the series applied: > > * test 7: normal boot is regressed even with > PcdCpuSmmStaticPageTable=FALSE, relative to test 1: > >> SmmInstallProtocolInterface: [EfiSmmReadyToLockProtocol] 0 >> Patch page table start ... >> Patch page table done! >> MemoryAttributesTable - NULL >> SetPageTableAttributes >> Start... >> ConvertPageEntryAttribute 0x7FF9A067->0x7FF9A065 >> >> ASSERT_EFI_ERROR (Status = Invalid Parameter) >> ASSERT UefiCpuPkg/PiSmmCpuDxeSmm/SmmCpuMemoryManagement.c(468): !EFI_ERROR (Status) > > Note that the processor model used in this test has no support for NX. > > * test 8: results identical to those of test 7 > > * test 13: S3 resume is unreliable (regression relative to test 4). End > of OVMF log (Fedora guest): > >> S3_BOOT_SCRIPT_LIB_TERMINATE_OPCODE >> S3BootScriptDone - Success >> Call AsmDisablePaging64() to return to S3 Resume in PEI Phase >> Install PPI: [PeiPostScriptTablePpi] >> Install PPI: [EfiEndOfPeiSignalPpi] >> Notify: PPI Guid: [EfiEndOfPeiSignalPpi], Peim notify entry point: 857895 >> PeiMpInitLib: CpuMpEndOfPeiCallback () invoked >> Transfer to 16bit OS waking vector - 9A1D0 > > QEMU log: > >> KVM internal error. Suberror: 1 >> KVM internal error. Suberror: 1 >> emulation failure >> emulation failure >> RAX=0000000000000001 RBX=0000000000000000 RCX=000000007ffdbf48 RDX=000000007fede058 >> RSI=0000000000000004 RDI=000000007fede040 RBP=0000000000000000 RSP=000000007e19f000 >> R8 =0000000000000000 R9 =0000000000000000 R10=0000000000000000 R11=0000000000000000 >> R12=0000000000000000 R13=0000000000000000 R14=0000000000000000 R15=0000000000000000 >> RIP=000000000009f0fd RFL=00010006 [-----P-] CPL=0 II=0 A20=1 SMM=0 HLT=0 >> ES =0030 0000000000000000 ffffffff 00c09300 DPL=0 DS [-WA] >> CS =0038 0000000000000000 ffffffff 00a09b00 DPL=0 CS64 [-RA] >> SS =0030 0000000000000000 ffffffff 00c09300 DPL=0 DS [-WA] >> DS =0030 0000000000000000 ffffffff 00c09300 DPL=0 DS [-WA] >> FS =0018 0000000000000000 ffffffff 00c09300 DPL=0 DS [-WA] >> GS =0018 0000000000000000 ffffffff 00c09300 DPL=0 DS [-WA] >> LDT=0000 0000000000000000 0000ffff 00008200 DPL=0 LDT >> TR =0000 0000000000000000 0000ffff 00008b00 DPL=0 TSS64-busy >> GDT= 000000007f294000 00000047 >> IDT= 000000007f294048 00000fff >> CR0=e0000011 CR2=0000000000000000 CR3=000000007ff80000 CR4=00000220 >> DR0=0000000000000000 DR1=0000000000000000 DR2=0000000000000000 DR3=0000000000000000 >> DR6=00000000ffff0ff0 DR7=0000000000000400 >> EFER=0000000000000500 >> Code=?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? >> RAX=0000000000000002 RBX=0000000000000000 RCX=000000007ffdbf48 RDX=000000007fede070 >> RSI=0000000000000004 RDI=000000007fede058 RBP=0000000000000000 RSP=000000007e1a7000 >> R8 =0000000000000000 R9 =0000000000000000 R10=0000000000000000 R11=0000000000000000 >> R12=0000000000000000 R13=0000000000000000 R14=0000000000000000 R15=0000000000000000 >> RIP=000000000009f0fd RFL=00010006 [-----P-] CPL=0 II=0 A20=1 SMM=0 HLT=0 >> ES =0030 0000000000000000 ffffffff 00c09300 DPL=0 DS [-WA] >> CS =0038 0000000000000000 ffffffff 00a09b00 DPL=0 CS64 [-RA] >> SS =0030 0000000000000000 ffffffff 00c09300 DPL=0 DS [-WA] >> DS =0030 0000000000000000 ffffffff 00c09300 DPL=0 DS [-WA] >> FS =0018 0000000000000000 ffffffff 00c09300 DPL=0 DS [-WA] >> GS =0018 0000000000000000 ffffffff 00c09300 DPL=0 DS [-WA] >> LDT=0000 0000000000000000 0000ffff 00008200 DPL=0 LDT >> TR =0000 0000000000000000 0000ffff 00008b00 DPL=0 TSS64-busy >> GDT= 000000007f294000 00000047 >> IDT= 000000007f294048 00000fff >> CR0=e0000011 CR2=0000000000000000 CR3=000000007ff80000 CR4=00000220 >> DR0=0000000000000000 DR1=0000000000000000 DR2=0000000000000000 DR3=0000000000000000 >> DR6=00000000ffff0ff0 DR7=0000000000000400 >> EFER=0000000000000500 >> Code=?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? > > This happened 1 time out of the 2 times I ran the test. > > * test 14: boot regression relative to test 4. The symptoms are > identical to those seen in test 7, that is: > >> SmmInstallProtocolInterface: [EfiSmmReadyToLockProtocol] 0 >> Patch page table start ... >> Patch page table done! >> MemoryAttributesTable - NULL >> SetPageTableAttributes >> Start... >> ConvertPageEntryAttribute 0x7FF98067->0x7FF98065 >> >> ASSERT_EFI_ERROR (Status = Invalid Parameter) >> ASSERT UefiCpuPkg/PiSmmCpuDxeSmm/SmmCpuMemoryManagement.c(468): !EFI_ERROR (Status) > > > Summary: > > - this series seems to break the boot with the Ia32 build of OVMF, > regardless of PcdCpuSmmStaticPageTable (cases 7 and 8), > > - it seems to break the boot with the Ia32X64 build of OVMF, with > PcdCpuSmmStaticPageTable=TRUE (case 14), > > - for the Ia32X64 build, with PcdCpuSmmStaticPageTable=FALSE, boot > works, but S3 becomes unreliable (case 13), > > - because there was no successful boot with > PcdCpuSmmStaticPageTable=TRUE, I couldn't check if and how the > increased SMRAM demand would impact the maximum count of bootable > VCPUs. (For this test, I should likely increase the guest-phys address > width from 36 bits anyway.) > > Thanks > Laszlo > > _______________________________________________ > edk2-devel mailing list > edk2-devel@lists.01.org > https://lists.01.org/mailman/listinfo/edk2-devel > _______________________________________________ > edk2-devel mailing list > edk2-devel@lists.01.org > https://lists.01.org/mailman/listinfo/edk2-devel >