On Fri, Jan 17, 2014 at 12:49:45AM -0600, Scott Duplichan wrote: > Gary Ching-Pang Lin [mailto:g...@suse.com] wrote: > > <...> > > ]> > It turned out the problem is caused by VfrCompile + glibc 2.18. > ]> > I built the programs in BaseTools/Source/C static-linked with glibc 2.17 > ]> > and replaced the binaries in BaseTools/Source/C/bin, and the OVMF image > that > ]> > is built with static-linked VfrCompile showed the secure boot menu as > ]> > expected. So, either the glibc commit is buggy, or some black magic in > new > ]> > gcc/glibc causes the problem. > > Isn't vfrcompile an ordinary application? If it is, that > rules out a problem related to any unique requirements of > the EDK2 environment. It seems unlikely that a released > glibc memcpy is buggy. Is it possible that the memcpy() in > VfrFormPkg.cpp should have been memmove() all along? If the > buffers overlap, memcpy may or may not work, depending on the > implementation. Maybe glibc 2.17=>2.18 changed the memcpy > implementation such that an incorrect memcpy call is now > exposed. It is at least worth verifying no buffer overlap > before filing a bug report against glibc memcpy. You are right. I printed the arguements of
memcpy (LastFormEndAddr, InsertOpcodeAddr, InsertOpcodeNode->mBufferFree - InsertOpcodeAddr) The result: 10827372 10827374 46 The buffer is obviously overlapped. So we need a more detailed check in VfrCompile to avoid the misused memcpy. (or just replace all memcpy with memmove) Thanks! Gary Lin ------------------------------------------------------------------------------ CenturyLink Cloud: The Leader in Enterprise Cloud Services. Learn Why More Businesses Are Choosing CenturyLink Cloud For Critical Workloads, Development Environments & Everything In Between. Get a Quote or Start a Free Trial Today. http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk _______________________________________________ edk2-devel mailing list edk2-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/edk2-devel