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
