From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id 06AC520958BD8 for ; Mon, 11 Sep 2017 06:24:04 -0700 (PDT) Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.phx2.redhat.com [10.5.11.16]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 42BFE23735C; Mon, 11 Sep 2017 13:26:59 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 42BFE23735C Authentication-Results: ext-mx09.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx09.extmail.prod.ext.phx2.redhat.com; spf=fail smtp.mailfrom=lersek@redhat.com Received: from lacos-laptop-7.usersys.redhat.com (ovpn-116-112.phx2.redhat.com [10.3.116.112]) by smtp.corp.redhat.com (Postfix) with ESMTP id 1A88458825; Mon, 11 Sep 2017 13:26:56 +0000 (UTC) To: "Shi, Steven" , Paulo Alcantara , edk2-devel-01 Cc: "Ni, Ruiyu" , "Dong, Eric" , "Zeng, Star" , Ard Biesheuvel References: <20170910001304.8628-1-lersek@redhat.com> <06C8AB66E78EE34A949939824ABE2B313B57E700@shsmsx102.ccr.corp.intel.com> <5d0d40da-5d93-2be7-f8ef-73e981b48f49@redhat.com> <06C8AB66E78EE34A949939824ABE2B313B57EAA3@shsmsx102.ccr.corp.intel.com> <06C8AB66E78EE34A949939824ABE2B313B57F227@shsmsx102.ccr.corp.intel.com> From: Laszlo Ersek Message-ID: <0daa889f-61a7-59be-30a2-00fa71b2dbcb@redhat.com> Date: Mon, 11 Sep 2017 15:26:55 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <06C8AB66E78EE34A949939824ABE2B313B57F227@shsmsx102.ccr.corp.intel.com> X-Scanned-By: MIMEDefang 2.79 on 10.5.11.16 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.38]); Mon, 11 Sep 2017 13:26:59 +0000 (UTC) Subject: Re: [PATCH 0/5] MdeModulePkg: UDF fixes and cleanups X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Sep 2017 13:24:04 -0000 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit On 09/11/17 15: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_9327751.iso > > I've submitted a bug for this issue: https://bugzilla.tianocore.org/show_bug.cgi?id=704. Right, I saw the report (via ), thank you for filing it. I asked Paulo a few minutes ago to register in the TianoCore Bugzilla, and to take the BZ. I don't intend to co-maintain UdfDxe permanently, aside from one-off patches and reviews, exactly like with any other MdeModulePkg driver. I'm totally unfamiliar with UdfDxe code, I'm just interested in using the feature. The only reason I sent these five patches over the weekend is that the initial code drop, technically committed by me, broke the build with CLANG38, and Paulo wasn't near his computer. I wanted to fix the build breakage ASAP. If you find other issues, please continue filing BZs, and Paulo should please continue helping out with them. Thanks! Laszlo > > 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:2136:18 > ShellSearchHandle > /home/jshi19/wksp_efi/edk2/ShellPkg/Application/Shell/ShellProtocol.c:2413:14 > EfiShellFindFiles > /home/jshi19/wksp_efi/edk2/ShellPkg/Application/Shell/ShellProtocol.c:2586:18 > EfiShellOpenFileList > /home/jshi19/wksp_efi/edk2/ShellPkg/Application/Shell/ShellProtocol.c:2666:12 > ShellOpenFileMetaArg > /home/jshi19/wksp_efi/edk2/ShellPkg/Library/UefiShellLib/UefiShellLib.c:1570: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: > ... > > Steven Shi > Intel\SSG\STO\UEFI Firmware > > Tel: +86 021-61166522 > iNet: 821-6522 > >> -----Original Message----- >> From: Paulo Alcantara [mailto:pcacjr@zytor.com] >> Sent: Sunday, September 10, 2017 11:52 PM >> To: Shi, Steven ; Laszlo Ersek ; >> edk2-devel-01 >> Cc: Ni, Ruiyu ; Dong, Eric ; Zeng, >> Star ; Ard Biesheuvel >> 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:lersek@redhat.com] >>>> Sent: Sunday, September 10, 2017 9:52 PM >>>> To: Shi, Steven ; edk2-devel-01 >>> devel@lists.01.org> >>>> Cc: Ni, Ruiyu ; Dong, Eric ; >> Zeng, >>>> Star ; Ard Biesheuvel >>>> 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 >>>