From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-in7.apple.com (mail-out7.apple.com [17.151.62.29]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id B22E31A1E30 for ; Mon, 15 Aug 2016 09:11:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1471277491; x=2335191091; h=From:Sender:Reply-To:Subject:Date:Message-id:To:Cc:MIME-version:Content-type: Content-transfer-encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-reply-to:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=RJTqHnMo58JfnJZzKiF4VaL7yXyAPY4h0GEQppFvPV4=; b=2dFdUaHQHpMf2RauKYzbff/VeCu0QjsGIPw3Y2LO8XlOtlaiGeEm7DCov6IcvhaN sVLKvi0vh41w0sTDlhuv8lNJl7jjoS3ffEGfXF5HZMDnIvgMia8ZIU28FRC+JtXG ksUNJFDyWdAZt9mvencrHgfluXozCEZTUTanQFCA+5xg2DG13QWG+DZxWGU8ferL vTNf+QPMitutua97KfujyBHghxvZpblUjTRIwOFm/2gvX6ODmpLgPW0fs7FnK0UX 0Am2lebKnt34Wvf8pQOSpAH15QXkRhPk7j+LGDXFoML1irmVz4cSKOyi2vaC6lZO kXq6zYcx97uOw9GVWN/hxw==; Received: from relay5.apple.com (relay5.apple.com [17.128.113.88]) by mail-in7.apple.com (Apple Secure Mail Relay) with SMTP id A9.E0.17422.3B9E1B75; Mon, 15 Aug 2016 09:11:31 -0700 (PDT) X-AuditID: 11973e16-f793f6d00000440e-fd-57b1e9b39854 Received: from nwk-mmpp-sz11.apple.com (nwk-mmpp-sz11.apple.com [17.128.115.155]) by relay5.apple.com (Apple SCV relay) with SMTP id AD.D4.30701.2B9E1B75; Mon, 15 Aug 2016 09:11:30 -0700 (PDT) MIME-version: 1.0 Received: from [17.153.67.115] by nwk-mmpp-sz11.apple.com (Oracle Communications Messaging Server 8.0.1.1.0 64bit (built Jun 15 2016)) with ESMTPSA id <0OBY00JM1KZ2OX00@nwk-mmpp-sz11.apple.com>; Mon, 15 Aug 2016 09:11:30 -0700 (PDT) Sender: afish@apple.com From: Andrew Fish In-reply-to: <4A89E2EF3DFEDB4C8BFDE51014F606A1155EB470@shsmsx102.ccr.corp.intel.com> Date: Mon, 15 Aug 2016 09:11:41 -0700 Cc: edk2-devel Message-id: <7A93D95B-B05C-46C3-9B82-9974FECDA0ED@apple.com> References: <7B465500-570A-4B78-B1F2-458C36E7DC08@apple.com> <4A89E2EF3DFEDB4C8BFDE51014F606A1155EB470@shsmsx102.ccr.corp.intel.com> To: "Gao, Liming" X-Mailer: Apple Mail (2.3112) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrJLMWRmVeSWpSXmKPExsUi2FAYobv55cZwg4un+Cz2HDrKbLHi3gZ2 ByaPxXteMnl0z/7HEsAUxWWTkpqTWZZapG+XwJWx+9BaxoLlBhXXb71hamBcpdrFyMkhIWAi 8Wj7flYIW0ziwr31bF2MXBxCAnsZJd4d3MYGU7TxUCc7ROIQo8SNxa/AOngFBCV+TL7H0sXI wcEsIC9x8LwsSJhZQEvi+6NWFoj6d4wSS3/1sIAkhAXEJd6d2cQMkhAWaGCUOPmqhx0kwSag LLFi/gcwm1MgTGLf+k1gC1gEVCWaP05mhJiqIfF19XZ2iMU2Ems33WSE2NDGKLF5ymawDSJA RQ/v/WaGOFtWYt+GBWD/SAjsYJO4NOsx0wRGkVlILp+FcPksJJcvYGRexSiUm5iZo5uZZ66X WFCQk6qXnJ+7iREU9tPtxHYwPlxldYhRgINRiYd3R/WGcCHWxLLiytxDjNIcLErivNv+rQ8X EkhPLEnNTk0tSC2KLyrNSS0+xMjEwSnVwMhy9YrNqVxdbdNzTdXzgoweyz2Zw7bT7/y6nVXF W/aw5x1dJOlfe0NeK2DeyiQO/edXwuwqTiZpfz+zpItTvOHhqUeRZ3evzWa2j4te5Hbo4Z3Z Be2T9s8Lv8HanPw5PfDQ6i2L7hZ61zT/N6nZ+WTL6R3CK8/KvmDfwfRjQ9m22wf/28y8f2qP EktxRqKhFnNRcSIAuo6H2VwCAAA= X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmphkeLIzCtJLcpLzFFi42IRbCierbvp5cZwg12TzS32HDrKbLHi3gZ2 ByaPxXteMnl0z/7HEsAUxWWTkpqTWZZapG+XwJWx+9BaxoLlBhXXb71hamBcpdrFyMkhIWAi sfFQJzuELSZx4d56ti5GLg4hgUOMEjcWv2IFSfAKCEr8mHyPpYuRg4NZQF7i4HlZkDCzgJbE 90etLBD17xgllv7qYQFJCAuIS7w7s4kZJCEs0MAocfJVD9gGNgFliRXzP4DZnAJhEvvWbwJb wCKgKtH8cTIjxFQNia+rt7NDLLaRWLvpJiPEhjZGic1TNoNtEAEqenjvNzPE2bIS+zYsYJvA KDgLybGzEI6dheTYBYzMqxgFilJzEitN9RILCnJS9ZLzczcxgsO0MGIH4/9lVocYBTgYlXh4 d1RvCBdiTSwrrswFhgYHs5II7/zHG8OFeFMSK6tSi/Lji0pzUosPMSYDPTCRWUo0OR8YQ3kl 8YYmJgYmxsZmxsbmJuakCSuJ896Zsy5cSCA9sSQ1OzW1ILUIZgsTB6dUA+P521zep5umnDry 99byVxILszf8yxL32f95lsINQ6ZtddVJTFzWV1ruB9blm186tWXLieqrgowyLxIPWlxZKMYg c2bFk8yN5h3qHsu1DX3Ci1U4tLXmWP3P3up8kn3arr8+kRtTeN94RYTdDZWrqMmP5ttxQl7s 3/Fp6Rqys14zHYtcO2FiVJMSS3FGoqEWc1FxIgBTtXl2lwIAAA== Subject: Re: [MdeModulePkg][PeiCore] I seemed to have crashed the PEI Core by grabbing memory from PeiTemporaryRamBase? 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: Mon, 15 Aug 2016 16:11:31 -0000 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII > On Aug 15, 2016, at 8:54 AM, Gao, Liming wrote: > > Andrew: > In permanent memory, PeiCore places heap base as stack top. Heap is above stack. There is no hole between them. SEC needs to follow this layout and migrate the temporary memory to permanent memory. It should copy TemporaryRam HEAP and STACK range separately. HEAP range is specified by PeiTemporaryRamBase and PeiTemporaryRamSize, and STACK range is specified by StackBase and StackSize. The grabbed memory is not migrated, because PeiCore doesn't know it. But, EmulatorPkg Sec SecTemporaryRamSupport() migrates the whole temporary memory together. The grabbed memory is also migrated and wrongly regarded as heap data. So, the fix is to update SecTemporaryRamSupport() implementation in SEC. > Limiing, I don't see any info in the PPI definition or the PI spec that defines the heap and stack are copied separately? The PPI just passes the entire ranges? That is why I assumes in the PPI case the offsets should be relative to the big shift? /** This service of the EFI_PEI_TEMPORARY_RAM_SUPPORT_PPI that migrates temporary RAM into permanent memory. @param PeiServices Pointer to the PEI Services Table. @param TemporaryMemoryBase Source Address in temporary memory from which the SEC or PEIM will copy the Temporary RAM contents. @param PermanentMemoryBase Destination Address in permanent memory into which the SEC or PEIM will copy the Temporary RAM contents. @param CopySize Amount of memory to migrate from temporary to permanent memory. @retval EFI_SUCCESS The data was successfully returned. @retval EFI_INVALID_PARAMETER PermanentMemoryBase + CopySize > TemporaryMemoryBase when TemporaryMemoryBase > PermanentMemoryBase. **/ typedef EFI_STATUS (EFIAPI * TEMPORARY_RAM_MIGRATION)( IN CONST EFI_PEI_SERVICES **PeiServices, IN EFI_PHYSICAL_ADDRESS TemporaryMemoryBase, IN EFI_PHYSICAL_ADDRESS PermanentMemoryBase, IN UINTN CopySize ); Thanks, Andrew Fish > Thanks > Liming > -----Original Message----- > From: edk2-devel [mailto:edk2-devel-bounces@lists.01.org] On Behalf Of Andrew Fish > Sent: Saturday, August 13, 2016 7:25 AM > To: edk2-devel > Subject: [edk2] [MdeModulePkg][PeiCore] I seemed to have crashed the PEI Core by grabbing memory from PeiTemporaryRamBase? > > I grabbed some memory between SEC and the PEI Core by adjusting SecCoreData-> PeiTemporaryRamBase and SecCoreData-> PeiTemporaryRamSize. > > When looking at the code I don't really understand the logic of the algorithm? So maybe I'm doing something wrong. > > This adjustment does not seem right to me? > https://github.com/tianocore/edk2/blob/master/MdeModulePkg/Core/Pei/Dispatcher/Dispatcher.c#L768 > // > // Heap Offset > // > BaseOfNewHeap = TopOfNewStack; > if (BaseOfNewHeap >= (UINTN)SecCoreData->PeiTemporaryRamBase) { > Private->HeapOffsetPositive = TRUE; > Private->HeapOffset = (UINTN)(BaseOfNewHeap - (UINTN)SecCoreData->PeiTemporaryRamBase); > } else { > Private->HeapOffsetPositive = FALSE; > Private->HeapOffset = (UINTN)((UINTN)SecCoreData->PeiTemporaryRamBase - BaseOfNewHeap); > } > > > The above code seems to be making a very strange adjustment. I noticed the adjustment in my failing case was off by 0xC0 which is the amount of memory I carved out prior to entering the PEI Core. > > https://github.com/tianocore/edk2/blob/master/MdeModulePkg/Core/Pei/Dispatcher/Dispatcher.c#L796 > > // > // Temporary Ram Support PPI is provided by platform, it will copy > // temporary memory to permenent memory and do stack switching. > // After invoking Temporary Ram Support PPI, the following code's > // stack is in permanent memory. > // > TemporaryRamSupportPpi->TemporaryRamMigration ( > PeiServices, > TemporaryRamBase, > (EFI_PHYSICAL_ADDRESS)(UINTN)(TopOfNewStack - TemporaryStackSize), > TemporaryRamSize > ); > > > And this is also a case in which the stack got bigger. But it seems to me the shift if really defined by TemporaryRamBase, TopOfNewStack, and TemporaryStackSize in this case. > > The failure I hit was OldCoreData->Fv pointer was shifted so when the PPI was called the system crashed. Is this a bug in the gEfiTemporaryRamSupportPpiGuid path? > > If I changed the HeadOffset algorithm my crash went away? Private->HeapOffset = ((UINTN)TopOfNewStack - TemporaryStackSize) - TemporaryRamBase; > > Thanks, > > Andrew Fish > > PS My failure case was the EmulatorPkg. I've not had a chance to verify this failure in the open source yet, but I'm guessing reversing this #if will make it happen. > > > https://github.com/tianocore/edk2/blob/master/EmulatorPkg/Sec/Sec.c#L107 > > #if 0 > // Tell the PEI Core to not use our buffer in temp RAM > SecPpiList = (EFI_PEI_PPI_DESCRIPTOR *)SecCoreData->PeiTemporaryRamBase; > SecCoreData->PeiTemporaryRamBase = (VOID *)((UINTN)SecCoreData->PeiTemporaryRamBase + SecReseveredMemorySize); > SecCoreData->PeiTemporaryRamSize -= SecReseveredMemorySize; > #else > { > // > // When I subtrack from SecCoreData->PeiTemporaryRamBase PEI Core crashes? Either there is a bug > // or I don't understand temp RAM correctly? > // > EFI_PEI_PPI_DESCRIPTOR PpiArray[10]; > > SecPpiList = &PpiArray[0]; > ASSERT (sizeof (PpiArray) >= SecReseveredMemorySize); > } > #endif > > > > > _______________________________________________ > 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