Hey Bruce, Sorry if I am wasting your time, but where exactly is the problem?
I don't think these strings can ever be statically allocated. If pointers to stack variables were used, the strings would be theoretically invalid the moment the exposing function returns. Furthermore they can't be part oft he struct itself as that would change the offsets of all other members after the string. Hence I think it can be concluded they are always dynamically allocated. And as one can be sure they are dynamically allocated, I think it's the task of the function that uninstalls the protocol to free the two buffers. Should the protocol not be uninstalled till ExitBootServices(), it doesn't matter either because the OS loader may treat Boot Services code and data as free space. Did I miss something? Regards, Marvin. > -----Original Message----- > From: edk2-devel [mailto:[email protected]] On Behalf Of > Bruce Cran > Sent: Thursday, July 7, 2016 9:36 PM > To: [email protected] > Subject: [edk2] Firmware Management Protocol: CHAR16* fields in > EFI_FIRMWARE_IMAGE_DESCRIPTOR > > Before I go hassling the USWG, I thought I'd check here in case anyone > knows. > > In the Firmware Management Protocol introduced in UEFI 2.3, there's a > EFI_FIRMWARE_IMAGE_DESCRIPTOR structure that has two CHAR16* fields, > 'ImageIdName' and 'VersionName'. The UEFI spec doesn't say anything > about memory allocation, but they're strings that at least in our driver are > dynamically allocated. > > Since there's no FMP 'cleanup' function, I'm wondering if there was some > sort of mistake specifying those, because I don't see a way to avoid leaking > memory. > > -- > Bruce Cran > _______________________________________________ > 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
