Hey Andrew, I have missed that it's not about the protocol directly, but about a returned data structure, so please excuse me!
Thanks, Marvin. > -----Original Message----- > From: [email protected] [mailto:[email protected]] > Sent: Thursday, July 7, 2016 10:33 PM > To: Marvin H?user <[email protected]> > Cc: [email protected]; Bruce Cran <[email protected]> > Subject: Re: [edk2] Firmware Management Protocol: CHAR16* fields in > EFI_FIRMWARE_IMAGE_DESCRIPTOR > > > > On Jul 7, 2016, at 1:27 PM, Marvin H?user <[email protected]> > wrote: > > > > 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? > > > > Marvin, > > I think your logic is sound in general. A protocol's structure could be a > global > or malloc'ed and as long as the protocol is installed that data exists. You > only > need to clean up that data if the protocol is uninstalled from the handle. > Bruce is asking about a protocol member function that returns a data > structure into a caller allocated buffer (hopefully I got that right) that > contains > pointers to other items. So conceptually it could be a different malloc'ed > buffer leaked on every call? So I think it is a less clear cut case. > > Thanks, > > Andrew Fish > > > 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 _______________________________________________ edk2-devel mailing list [email protected] https://lists.01.org/mailman/listinfo/edk2-devel
