search

pbatard / EfiFs

EFI FileSystem drivers
https://efi.akeo.ie
GNU General Public License v3.0
506 stars 77 forks source link

Synchronous Exception with recent Linaro snapshots for AARCH64 #18

Closed pbatard closed 4 years ago

pbatard commented 4 years ago

When using QEMU.efi from https://snapshots.linaro.org/components/kernel/leg-virt-tianocore-edk2-upstream/3852/QEMU-AARCH64/RELEASE_GCC5/ you get the following when trying to load the driver:

UEFI Interactive Shell v2.2
EDK II
UEFI v2.70 (EDK II, 0x00010000)
Mapping table
      FS0: Alias(s):HD0b:;BLK1:
          PciRoot(0x0)/Pci(0x1,0x0)/HD(1,MBR,0xBE1AFDFA,0x3F,0xFBFC1)
     BLK4: Alias(s):
          VenHw(93E34C7E-B50E-11DF-9223-2443DFD72085,00)
     BLK0: Alias(s):
          PciRoot(0x0)/Pci(0x1,0x0)
     BLK2: Alias(s):
          PciRoot(0x0)/Pci(0x2,0x0)
     BLK3: Alias(s):
          PciRoot(0x0)/Pci(0x2,0x0)/HD(1,MBR,0x0059785B,0x800,0x3800)
Shell> set FS_LOGGING 4
Shell> load fs0:\exfat_aa64.efi
FS driver installed.
Image 'FS0:\exfat_aa64.efi' loaded at 43913000 - Success
FSBindingSupported
FSBindingStart
error: not a FAT filesystem.
FSBindingSupported
FSBindingStart
FSInstall: PciRoot(0x0)/Pci(0x2,0x0)/HD(1,MBR,0x0059785B,0x800,0x3800)

Synchronous Exception at 0x0000000043919BD0

Synchronous Exception at 0x0000000043919BD0

This does not happen with older versions of Linaro QEMU, such as ones from 2017 which is the one we provide for testing on the website and also doesn't happen on real hardware with up to date UEFI and Shell, such as with the currebt Raspberry Pi 4 UEFI firmware.

This is also not a regression from 1.4, as version 1.3 of the drivers exhibit the same issue...

pbatard commented 4 years ago

Best I can tell right now is that the crash is triggered by this line from grub_file.c:

CopyMem(&NewFile->EfiFile, &FileSystem->RootFile->EfiFile, sizeof(EFI_FILE));
pbatard commented 4 years ago

And the issue is that FileSystem->RootFile is not properly allocated when we create the file system. Ouch!

At this stage, I'm actually more surprised that the QEMU firmware is the only one crashing because of this. I may have to produce a new release that includes the fix for this issue, because it's a fairly critical one...