Hi Paulo, Your fix works for me. The "Null Pointer Use" issue disappears after apply your new assignment patch. Thanks!
Steven Shi Intel\SSG\STO\UEFI Firmware Tel: +86 021-61166522 iNet: 821-6522 > -----Original Message----- > From: Paulo Alcantara [mailto:pca...@zytor.com] > Sent: Monday, September 11, 2017 9:52 PM > To: Shi, Steven <steven....@intel.com>; Laszlo Ersek <ler...@redhat.com>; > edk2-devel-01 <edk2-devel@lists.01.org> > Cc: Ni, Ruiyu <ruiyu...@intel.com>; Dong, Eric <eric.d...@intel.com>; Zeng, > Star <star.z...@intel.com>; Ard Biesheuvel <ard.biesheu...@linaro.org> > Subject: Re: [edk2] [PATCH 0/5] MdeModulePkg: UDF fixes and cleanups > > Hi Steven, > > On 11/09/2017 10:07, Shi, Steven wrote: > > Hi Laszlo, > > Your code is good. But there is a "Null Pointer Use" issue, which is a > undefined behavior in C spec, in > edk2/MdeModulePkg/Universal/Disk/UdfDxe/File.c, line:696, column: 7 and > line:707, column: 14. > > > > Line695: > > FileIdentifierDesc = PrivFileData->File.FileIdentifierDesc; > > if (IS_FID_DIRECTORY_FILE (FileIdentifierDesc)) { > > ... > > > > The above FileIdentifierDesc can be NULL if you run a .efi in a Udf > > partition. > And the later IS_FID_DIRECTORY_FILE (FileIdentifierDesc) is unsafe if > FileIdentifierDesc == NULL. You can test it with below extra code which add > debug output when FileIdentifierDesc == NULL, and check the log after load > and run something in a Udf partition. > > > > +++ b/MdeModulePkg/Universal/Disk/UdfDxe/File.c > > @@ -693,6 +693,11 @@ UdfSetPosition ( > > PrivFileData = PRIVATE_UDF_FILE_DATA_FROM_THIS (This); > > > > FileIdentifierDesc = PrivFileData->File.FileIdentifierDesc; > > + if (FileIdentifierDesc == NULL) { > > + DEBUG ((EFI_D_ERROR, "FileIdentifierDesc == NULL!\n")); > > + return Status; > > + } > > + > > if (IS_FID_DIRECTORY_FILE (FileIdentifierDesc)) { > > // > > // If the file handle is a directory, the _only_ position that may be > > set is > > > > I followed the Paulo's suggestion, and found this issue when using the Udf > partition of Windows 10 Enterprise ISO image on qemu. Below is my qemu > command: > > /usr/local/bin/qemu-system-x86_64 -m 5120 -enable-kvm -machine pc- > q35-2.9 -bios OVMF.fd -serial file:serial.log -cdrom /media/jshi19/My\ > Passport/OSImage/ISO/winserver/en_windows_server_2016_x64_dvd_9327 > 751.iso > > > > I've submitted a bug for this issue: > https://bugzilla.tianocore.org/show_bug.cgi?id=704. > > > > I found this issue by edk2 llvm undefined behavior sanitizer, and below is > the sanitizer output. FYI. > > > /home/jshi19/wksp_efi/edk2/MdeModulePkg/Universal/Disk/UdfDxe/File.c, > line:0x02B8, column:0x0007 ErrorType = NullPointerUse: member access > within null pointer of type 'UDF_FILE_IDENTIFIER_DESCRIPTOR' > > ASAN MEMORY ACCESS check fail! __ubsan_handle_type_mismatch_v1 is > called: > > UdfSetPosition > > > /home/jshi19/wksp_efi/edk2/MdeModulePkg/Universal/Disk/UdfDxe/File.c: > 696:7 > > EfiShellFindFilesInDir > > > /home/jshi19/wksp_efi/edk2/ShellPkg/Application/Shell/ShellProtocol.c:213 > 6:18 > > ShellSearchHandle > > > /home/jshi19/wksp_efi/edk2/ShellPkg/Application/Shell/ShellProtocol.c:241 > 3:14 > > EfiShellFindFiles > > > /home/jshi19/wksp_efi/edk2/ShellPkg/Application/Shell/ShellProtocol.c:258 > 6:18 > > EfiShellOpenFileList > > > /home/jshi19/wksp_efi/edk2/ShellPkg/Application/Shell/ShellProtocol.c:266 > 6:12 > > ShellOpenFileMetaArg > > > /home/jshi19/wksp_efi/edk2/ShellPkg/Library/UefiShellLib/UefiShellLib.c:15 > 70:14 > > > > > /home/jshi19/wksp_efi/edk2/MdeModulePkg/Universal/Disk/UdfDxe/File.c, > line:0x02C3, column:0x000E ErrorType = NullPointerUse: member access > within null pointer of type 'UDF_FILE_IDENTIFIER_DESCRIPTOR' > > ASAN MEMORY ACCESS check fail! __ubsan_handle_type_mismatch_v1 is > called: > > ... > > Thank you for catching this bug up. I think this issue is related to > accessing a File Identifier Descriptor from a root directory file -- > e.g., this should be "FileIdentifierDesc = > PrivFileData->Root->FileIdentifierDesc;" > > Could you please replace the broken assignment with: > > FileIdentifierDesc = _FILE(PrivFileData)->FileIdentifierDesc; > ASSERT (FileIdentifierDesc != NULL); > ... > > Tell me if that worked for you. If so, I could send a formal patch > fixing this issue later. > > (BTW, I do apologize the late replies but I'm only able to work on this > in my free time) > > Thanks, > Paulo > > > > > Steven Shi > > Intel\SSG\STO\UEFI Firmware > > > > Tel: +86 021-61166522 > > iNet: 821-6522 > > > >> -----Original Message----- > >> From: Paulo Alcantara [mailto:pca...@zytor.com] > >> Sent: Sunday, September 10, 2017 11:52 PM > >> To: Shi, Steven <steven....@intel.com>; Laszlo Ersek > <ler...@redhat.com>; > >> edk2-devel-01 <edk2-devel@lists.01.org> > >> Cc: Ni, Ruiyu <ruiyu...@intel.com>; Dong, Eric <eric.d...@intel.com>; > Zeng, > >> Star <star.z...@intel.com>; Ard Biesheuvel <ard.biesheu...@linaro.org> > >> Subject: Re: [edk2] [PATCH 0/5] MdeModulePkg: UDF fixes and cleanups > >> > >> > >> > >> On 10/09/2017 11:27, Shi, Steven wrote: > >>> OK. Does the UDF image you created correctly show up as CD-ROM > >> content in Linux, e.g Fedora? > >> > >> The Fedora image I have (Fedora-Workstation-Live-x86_64-26-1.5.iso) > does > >> not contain a valid UDF file system, so you cannot use it for testing. > >> > >> To make sure it really doesn't, I used a "Philips UDF Conformance Tool" > >> that you can grab in [1], and the tool didn't find any valid UDF file > >> system in it. > >> > >> I've been using an unmodified Windows 10 Enterprise image that does > >> contain a valid UDF bridge disk image (ISO9660+ElTorito+UDF) to perform > >> my tests. > >> > >> Additionally, I use an USB stick that I format it with 'sudo mkudffs -b > >> 512 --media-type=hd /dev/sdX' and copy some files to it for testing > >> > >> BTW, when testing with OVMF AARCH64, I was using my USB stick that > >> showed up correctly as 'fsX' in UEFI shell, but with the Windows 10 > >> Enterprise ISO image, it didn't. I looked at the logs to see what was > >> going on and I found out that the emulated CD-ROM drive is reporting a > >> block size of 512 instead of 2048 -- which seems wrong to me. With > >> 'qemu-system-x86_64 -cdrom', it reports a block size of 2048. > >> > >> The Partition driver is still able to find a valid ElTorito partition > >> because, regardless the device block size, it always use a logical block > >> size of 2048 starting at 32K. In UDF, when searching for AVDPs (Anchor > >> Volume Descriptor Pointers), we search for them at fixed locations: 256, > >> N - 256, N and 512 -- but, with a block size of 512, the locations > >> change to 1024, N - 1024, N and 2048 -- thus breaking the volume > >> recognition sequence. > >> > >> For testing the Windows image with a block size of 512, I used the > >> comformance tool with './udf_test -verbose 60 -blocksize 512 > >> ~/img/win_ent10.iso' and it failed to find a valid UDF file system. But > >> with a block size of 2048, it worked. > >> > >> Is there any reason for reporting a block size of 512 when using > >> '-cdrom' option in qemu-system-aarch64? Is that a bug? Or am I missing > >> something here? > >> > >> Thanks! > >> Paulo > >> > >> [1] - https://www.lscdweb.com/registered/udf_verifier.html > >> > >>> > >>> > >>> Steven Shi > >>> Intel\SSG\STO\UEFI Firmware > >>> > >>> Tel: +86 021-61166522 > >>> iNet: 821-6522 > >>> > >>>> -----Original Message----- > >>>> From: Laszlo Ersek [mailto:ler...@redhat.com] > >>>> Sent: Sunday, September 10, 2017 9:52 PM > >>>> To: Shi, Steven <steven....@intel.com>; edk2-devel-01 <edk2- > >>>> de...@lists.01.org> > >>>> Cc: Ni, Ruiyu <ruiyu...@intel.com>; Dong, Eric <eric.d...@intel.com>; > >> Zeng, > >>>> Star <star.z...@intel.com>; Ard Biesheuvel > <ard.biesheu...@linaro.org> > >>>> Subject: Re: [edk2] [PATCH 0/5] MdeModulePkg: UDF fixes and > cleanups > >>>> > >>>> Hi Steven, > >>>> > >>>> On 09/10/17 10:38, Laszlo Ersek wrote: > >>>>> On 09/10/17 06:24, Shi, Steven wrote: > >>>>>> Hi Laszlo, > >>>>>> How could we configure the Qemu and test the UDF driver on OVMF? > >>>>> > >>>>> I guess you would format e.g. a DVD image with UDF, and attach it to > >>>>> QEMU like any other CD-ROM. > >>>> > >>>> I tried to look into this -- I tried several things, but nothing > >>>> produced an UDF image file that, when attached to the VM, would > show > >> up > >>>> in the UEFI shell as FSn: > >>>> > >>>> Google returned a bunch of pages, but all I found was: > >>>> - tips that didn't work (see above), > >>>> - confused users (like me) looking for solutions. > >>>> > >>>> So, at the moment, I have no idea how authoring UDF DVD images is > >>>> possible on Linux, so that they'd be recognized in edk2. > >>>> > >>>> (I'm interested in the edk2 UDF driver not because I want to "author" > >>>> UDF DVD images (ISO9660+ElTorito works just fine), but because some > >>>> optical media images that were given to me are formatted UDF-only. > >> They > >>>> can be translated into ISO9660+ElTorito off-line, but that's a chore.) > >>>> > >>>> Thanks, > >>>> Laszlo > >>> _______________________________________________ > >>> edk2-devel mailing list > >>> edk2-devel@lists.01.org > >>> https://lists.01.org/mailman/listinfo/edk2-devel > >>> > > _______________________________________________ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
