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?
-----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
