On 05/18/16 15:48, El-Haj-Mahmoud, Samer wrote: > Does it make sense to update the RAM Disk HII (at > \MdeModulePkg\Universal\Disk\RamDiskDxe) to allow creating a RAM Disk > of Type Reserved, for this kind of testing?
That's exactly what I suggested in http://thread.gmane.org/gmane.comp.bios.edk2.devel/10766/focus=10770 Namely, > [...] I think this question should be exposed with a checkbox on the > form: "will you want to boot from this RAM disk?" And then the answer > to that question should determine the type of memory the RAM disk is > allocated from. but it was not approved; Feng said later in the thread, > [...] For those ramdisk created from Ramdisk HII, the original > design intention is only for boot time use. I had not participated in the design, so I didn't question it. Thanks Laszlo > -----Original Message----- > From: edk2-devel [mailto:[email protected]] On Behalf Of Laszlo > Ersek > Sent: Wednesday, May 18, 2016 4:39 AM > To: Andrew Fish <[email protected]>; Foster, Matthew I > <[email protected]> > Cc: [email protected] <[email protected]> > Subject: Re: [edk2] Using the Shell to launch a kernel using a RAMDISK > > On 05/18/16 01:16, Andrew Fish wrote: >> >>> On May 17, 2016, at 4:08 PM, Foster, Matthew I <[email protected]> >>> wrote: >>> >>> Thanks Ersek, >>> >> >> Laszlo... > > That's right, thanks Andrew :) > >>> I did change my code to match what you have here as far as the >>> allocation. I did some more debugging and registered up a callback in >>> exit boot services, and did an integrity check of the memory I >>> previously allocated and put the ramdisk in. I checked the memory >>> right before I call loadimage (to launch the kernel), and then again >>> I check in the callback during exit boot services. So some point >>> between the memory actually does get changed. So it might be >>> something happening during exit boot services. >>> >>> Just a question, after allocating that memory as you mentioned below, >>> other code should not be able to allocate and use that same address >>> range right? >> >> The EFI Memory Map is well defined and you can read about it in >> Section 6.2 Memory Allocation Services. > > Yeah, once allocated (and not freed), those pages should never be handed out > to any other agent calling gBS->AllocatePool() or gBS->AllocatePages(). > > The memory corruption issue is very interesting. I have faced similar > earlier, several times. I've developed methods for trying to dealing with it > ("develop methods" is a fancy expression for just a few basic ideas, of > course :)) > > - The integrity check you mention. Since we are not talking about a malicious > attacker, just (likely) a genuine bug somewhere, the > CalculateCrc32() boot service is usually helpful in pointing out corruption. > > - CRC32 can also be computed on a set of smaller blocks, not just the entire > image. I usually don't try to keep the CRCs in an array (for later > comparison) -- instead I dump the CRCs to the debug log, and compare the > values (before vs. after) with text processing utilities. > > - Once you managed to narrow down the location of the corruption a little > bit, you can hexdump the entire block, and compare its before / after > contents. > > - Occasionally it can help to look at the ASCII representation of the > differring blocks. For example, many structures in edk2 start with a 32-bit > or 64-bit signature (see the SIGNATURE_32 and SIGNATURE_64 macros), and the > signature is usually an abbreviation of English words in ASCII. If you find > some signatures, you might be able to deduce where they come from (IOW, the > nature of the data discloses the origin of the data). > > [snip] > > Thanks > Laszlo > _______________________________________________ > edk2-devel mailing list > [email protected] > https://lists.01.org/mailman/listinfo/edk2-devel > _______________________________________________ edk2-devel mailing list [email protected] https://lists.01.org/mailman/listinfo/edk2-devel
