Hi Ard, Thanks for your quick reply.
I took the latest image from linaro site http://releases.linaro.org/14.08/openembedded/aarch64/vexpress64-openembedded_minimal-armv8-gcc-4.9_20140823-686.img.gz run following commands on image: zcat vexpress64-openembedded_minimal-armv8-gcc-4.9_20140823-686.img.gz > vexpress64-oe.img sudo mount -o loop,offset=32256 vexpress64-oe.img /mnt cd /mnt sync sudo umount /mnt Signed this image and try to load Image.signed, but I face similar error on loading signed kernel image. Please point me to the correct kernel image if mentioned image is not a valid one. Also, I am following the below mentioned wiki page: https://wiki.linaro.org/LEG/UEFIforQEMU Here, flow of shim->grub->kernel is not mentioned, so I am trying to load kernel directly from shell using below command: Image.signed root=/dev/vda2 console=ttyAMA0,38400n8 earlycon=pl011,0x9000000 Will this work in case of SECURE_BOOT? Thanks, Meenakshi -----Original Message----- From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org] Sent: Thursday, April 21, 2016 3:56 PM To: Meenakshi Aggarwal <meenakshi.aggar...@nxp.com> Cc: Laszlo Ersek <ler...@redhat.com>; edk2-devel@lists.01.org <edk2-de...@ml01.01.org> Subject: Re: [edk2] facing memory allocation failure on QEMU > On 21 apr. 2016, at 12:14, Meenakshi Aggarwal <meenakshi.aggar...@nxp.com> > wrote: > > Hi, > > > The issue seems more like of sbsigntool. > > I used vexpress64-oe.img image from below link: > http://releases.linaro.org/14.08/openembedded/aarch64/vexpress64-opene > mbedded_minimal-armv8-gcc-4.9_20140823-686.img.gz > > > I signed it using sbsigntool : > sbsign --key DB.key --cert DB.crt --output Image.signed Image > Do you mean you are signing the kernel image you took from that filesystem image? In that case, this is a known issue that was solved a long time ago. Please try signing a more recent kernel image. > > > After that I launch QEMU and try to execute Image.signed, but its > verification got failed: > > FSOpen: Open '\Image.signed' Success > FSOpen: Open '\Image.signed' Success > FatDiskIo: Cache Page OutBound occurred! > FatDiskIo: Cache Page OutBound occurred! > The image doesn't pass verification: > VenHw(837DCA9E-E874-4D82-B29A-23FE0E23D1E2,003E000A00000000)/HD(1,MBR, > 0x00000000,0x3F,0x21FC0)/\Image.signed > InstallProtocolInterface: 5B1B31A1-9562-11D2-8E3F-00A0C969723B > 795EC8C0 Unloading driver at 0x00000000000 Command Error Status: > Unsupported > > > > So I verify its signature using sbverify, then its verification failed with > following output: > > sbverify --cert DB.crt Image.signed > warning: file-aligned section .text extends beyond end of file > file_offset 0x160, regions[n].size 0x9e2e20, image->size 0x40c000 > warning: checksum areas are greater than image size. Invalid section table? > warning: checksum areas are greater than image size. Invalid section table? > No signature table present > Signature verification failed > b46476@uefi-workstation:/mnt$ > > > What is your opinion on this? Is this sbsign tool issue? > > > Thanks, > Meenakshi > > > -----Original Message----- > From: Laszlo Ersek [mailto:ler...@redhat.com] > Sent: Wednesday, April 20, 2016 5:16 PM > To: Ard Biesheuvel <ard.biesheu...@linaro.org>; Meenakshi Aggarwal > <meenakshi.aggar...@nxp.com> > Cc: edk2-devel@lists.01.org <edk2-de...@ml01.01.org> > Subject: Re: [edk2] facing memory allocation failure on QEMU > >> On 04/20/16 09:46, Ard Biesheuvel wrote: >> On 20 April 2016 at 09:33, Meenakshi Aggarwal >> <meenakshi.aggar...@nxp.com> wrote: >>> Hi, >>> >>> >>> I am trying to load a signed image from UEFI shell using QEMU, For any >>> signed image I faced following message (snapshot taken after loading grub): >>> >>> FS0:\> grubaa64-signed.efi >>> FSOpen: Open '\grubaa64-signed.efi' Success >>> FSOpen: Open '\grubaa64-signed.efi' Success >>> FSOpen: Open '\grubaa64-signed.efi' Success >>> FSOpen: Open '\grubaa64-signed.efi' Success >>> AllocatePoolPages: failed to allocate 497135 pages >>> AllocatePool: failed to allocate 2036264128 bytes >> >> You should try to find out where this allocation is attempted. >> Allocating 2 GB of pool memory is obviously not going to work >> >>> DxeImageVerification: MeasureVariable (Pcr - 7, EventType - >>> 800000E0, VariableName - db, VendorGuid - >>> D719B2CB-3D3A-4596-A3BC-DAD00E67656F) >>> MeasureBootPolicyVariable - Not Found >>> InstallProtocolInterface: 5B1B31A1-9562-11D2-8E3F-00A0C969723B >>> 795F3C00 Loading driver at 0x000781A3000 EntryPoint=0x000781A3400 >>> Loading driver at 0x000781A3000 EntryPoint=0x000781A3400 >>> InstallProtocolInterface: BC62157E-3E33-4FEC-9920-2D3B36D750DF >>> 795D3AD8 >>> InstallProtocolInterface: 752F3136-4E16-4FDC-A22A-E5F46812F4CA >>> 7EF31980............ >>> >>> >>> But image gets loaded successfully after this memory allocation failure. >>> These memory allocation failure is coming on executing any signed image. >>> >>> >>> I want to know the reason behind this error message. Am I missing something? >> >> Try to attach GDB when you run this. You can set a breakpoint on >> AllocatePool() to figure out the call stack that results in the bogus >> AllocatePool() call > > I think it could be a bug in the tools used for signing the image, and also a > bug in the LoadImage() boot service that doesn't catch bogus fields in the > image. > > Namely, if I filter the above log snippet through my sed script that replaces > common GUIDs with their symbolic constants, I get: > >> FS0:\> grubaa64-signed.efi >> FSOpen: Open '\grubaa64-signed.efi' Success >> FSOpen: Open '\grubaa64-signed.efi' Success >> FSOpen: Open '\grubaa64-signed.efi' Success >> FSOpen: Open '\grubaa64-signed.efi' Success >> AllocatePoolPages: failed to allocate 497135 pages >> AllocatePool: failed to allocate 2036264128 bytes >> DxeImageVerification: MeasureVariable (Pcr - 7, EventType - 800000E0, >> VariableName - db, VendorGuid - [EfiImageSecurityDatabase]) >> MeasureBootPolicyVariable - Not Found >> InstallProtocolInterface: [EfiLoadedImageProtocol] 795F3C00 Loading >> driver at 0x000781A3000 EntryPoint=0x000781A3400 Loading driver at >> 0x000781A3000 EntryPoint=0x000781A3400 >> InstallProtocolInterface: [EfiLoadedImageDevicePathProtocol] 795D3AD8 >> InstallProtocolInterface: [EfiShellParametersProtocol] 7EF31980............ > > Note how the error messages are printed after the FAT driver logs the opening > of the signed binary, but before EfiLoadedImageProtocol is installed. > > Actually, the error messages are printed even before the > "DxeImageVerification: MeasureVariable ..." message. > > That latter message comes from the following call path, in my opinion: > > CoreLoadImageCommon() > [MdeModulePkg/Core/Dxe/Image/Image.c] > gSecurity2->FileAuthentication > | gSecurity->FileAuthenticationState > SecurityStubAuthenticateState() > [MdeModulePkg/Universal/SecurityStubDxe/SecurityStub.c] > | Security2StubAuthenticate() > [MdeModulePkg/Universal/SecurityStubDxe/SecurityStub.c] > ExecuteSecurity2Handlers() > [MdeModulePkg/Library/DxeSecurityManagementLib/DxeSecurityManagementLib.c] > DxeImageVerificationHandler() > [SecurityPkg/Library/DxeImageVerificationLib/DxeImageVerificationLib.c] > IsSignatureFoundInDatabase() > [SecurityPkg/Library/DxeImageVerificationLib/DxeImageVerificationLib.c] > | IsForbiddenByDbx() > [SecurityPkg/Library/DxeImageVerificationLib/DxeImageVerificationLib.c] > | IsAllowedByDb() > [SecurityPkg/Library/DxeImageVerificationLib/DxeImageVerificationLib.c] > SecureBootHook() > [SecurityPkg/Library/DxeImageVerificationLib/Measurement.c] > MeasureVariable() > [SecurityPkg/Library/DxeImageVerificationLib/Measurement.c] > > I think a header in the binary that is related to image signing may be bogus. > The verification code doesn't catch it. (The allocation size 2036264128 > (approx. 1941 MB) indicates a 32-bit underflow I guess?) It is passed along > to AllocatePool(), which fails. > > This might well be a vulnerability in edk2 (unintentionally triggered by a > malformed signed binary). > > Thanks > Laszlo _______________________________________________ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
