From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [216.205.24.124]) by mx.groups.io with SMTP id smtpd.web08.127.1624556970462277879 for ; Thu, 24 Jun 2021 10:49:30 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=EVJkfHOm; spf=pass (domain: redhat.com, ip: 216.205.24.124, mailfrom: lersek@redhat.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1624556969; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=/SY1A2o4gbc4AwCNSV+nUFmuYYOtNlvLmdI/S1pxshc=; b=EVJkfHOmCwhZKt4XRTGw4L2s0RRTMQFWuGGSvgS1Nr8EXmMYzxe0M/VQzFK6QKl49sAnSx IGHlIux1Cp83SPL9+tbuBwbkVyN75hrGYd57Qo/kk7Z4O1awrlHYZc5jktQR++IRbSF3f/ nrNTgXkR9Dm3wEBgpWIvOyy+6xTXCLI= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-201-ryPD_jYxPYS2CelR1AGI2g-1; Thu, 24 Jun 2021 13:49:26 -0400 X-MC-Unique: ryPD_jYxPYS2CelR1AGI2g-1 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 mimecast-mx01.redhat.com (Postfix) with ESMTPS id 68E4F1005E53; Thu, 24 Jun 2021 17:49:24 +0000 (UTC) Received: from lacos-laptop-7.usersys.redhat.com (ovpn-114-106.ams2.redhat.com [10.36.114.106]) by smtp.corp.redhat.com (Postfix) with ESMTPS id B10CD5C1CF; Thu, 24 Jun 2021 17:49:22 +0000 (UTC) Subject: Re: [edk2-devel] [PATCH v2 2/3] OvmfPkg/GenericQemuLoadImageLib: Read cmdline from QemuKernelLoaderFs To: devel@edk2.groups.io, dovmurik@linux.ibm.com Cc: Ard Biesheuvel , Jordan Justen , James Bottomley , Tobin Feldman-Fitzthum References: <20210617121700.2883073-1-dovmurik@linux.ibm.com> <20210617121700.2883073-3-dovmurik@linux.ibm.com> From: "Laszlo Ersek" Message-ID: Date: Thu, 24 Jun 2021 19:49:21 +0200 MIME-Version: 1.0 In-Reply-To: <20210617121700.2883073-3-dovmurik@linux.ibm.com> X-Scanned-By: MIMEDefang 2.79 on 10.5.11.16 Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=lersek@redhat.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Hi Dov, On 06/17/21 14:16, Dov Murik wrote: > Remove the QemuFwCfgLib interface used to read the QEMU cmdline > (-append argument) and the initrd size. Instead, use the synthetic > filesystem QemuKernelLoaderFs which has three files: "kernel", "initrd", > and "cmdline". > > Cc: Laszlo Ersek > Cc: Ard Biesheuvel > Cc: Jordan Justen > Cc: James Bottomley > Cc: Tobin Feldman-Fitzthum > Signed-off-by: Dov Murik > --- > OvmfPkg/Library/GenericQemuLoadImageLib/GenericQemuLoadImageLib.inf | 2 +- > OvmfPkg/Library/GenericQemuLoadImageLib/GenericQemuLoadImageLib.c | 145 ++++++++++++++++++-- > 2 files changed, 133 insertions(+), 14 deletions(-) This update seems to address everything that Ard requested under v1; thanks. My comments: (1) I spent a lot of time reviewing your patch. Unfortunately, I found a preexistent bug in both QemuLoadImageLib instances, which we should fix first, in two separate patches. The bug was introduced in commit ddd2be6b0026 ("OvmfPkg: provide a generic implementation of QemuLoadImageLib", 2020-03-05). Unfortunately I missed the bug in my original review. In said commit, the QemuLoadKernelImage() function [OvmfPkg/Library/GenericQemuLoadImageLib/GenericQemuLoadImageLib.c] refactored / reimplemented the logic from the TryRunningQemuKernel() function [ArmVirtPkg/Library/PlatformBootManagerLib/QemuKernel.c]. If we now check out the tree at ddd2be6b0026, and compare the above two functions, we notice the following: (1a) TryRunningQemuKernel() downloads all three blobs via fw_cfg in the beginning, and *always* frees all successfully downloaded blobs at the end, under the "FreeBlobs" label. (1b) In QemuLoadKernelImage(), the kernel and initrd fw_cfg blobs are owned by the QemuKernelLoaderFsDxe driver; only the command line blob is downloaded from fw_cfg. Not freeing the former two blobs (kernel and initrd) makes sense. *However*, the command line blob should *still* be freed, even if QemuLoadKernelImage() succeeds! That's because we have no use for the command line fw_cfg blob, after it is translated to LoadOptions. The bug is that QemuLoadKernelImage() leaks "CommandLine" on success. The same issue was introduced in the other lib instance [OvmfPkg/Library/X86QemuLoadImageLib/X86QemuLoadImageLib.c], in commit 7c47d89003a6 ("OvmfPkg: implement QEMU loader library for X86 with legacy fallback", 2020-03-05). The fix is identical between both library instances: > @@ -193,14 +193,16 @@ QemuLoadKernelImage ( > } > > *ImageHandle = KernelImageHandle; > - return EFI_SUCCESS; > + Status = EFI_SUCCESS; > > FreeCommandLine: > if (CommandLineSize > 0) { > FreePool (CommandLine); > } > UnloadImage: > - gBS->UnloadImage (KernelImageHandle); > + if (EFI_ERROR (Status)) { > + gBS->UnloadImage (KernelImageHandle); > + } > > return Status; > } Can you please submit this fix twice, in two separate patches at the *very front* of this series, one patch for each lib instance? Something like: #1 OvmfPkg/GenericQemuLoadImageLib: plug cmdline blob leak on success ... Reported-by: Laszlo Ersek Fixes: ddd2be6b0026abcd0f819b3915fc80c3de81dd62 #2 OvmfPkg/X86QemuLoadImageLib: plug cmdline blob leak on success ... Reported-by: Laszlo Ersek Fixes: 7c47d89003a6f8f7f6f0ce8ca7d3e87c630d14cc Thank you in advance! Then, comments on your actual patch: (2) The bugzilla ticket should be referenced in the commit message please, above your signoff: Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=3457 On 06/17/21 14:16, Dov Murik wrote: > > diff --git a/OvmfPkg/Library/GenericQemuLoadImageLib/GenericQemuLoadImageLib.inf b/OvmfPkg/Library/GenericQemuLoadImageLib/GenericQemuLoadImageLib.inf > index b262cb926a4d..f462fd6922cf 100644 > --- a/OvmfPkg/Library/GenericQemuLoadImageLib/GenericQemuLoadImageLib.inf > +++ b/OvmfPkg/Library/GenericQemuLoadImageLib/GenericQemuLoadImageLib.inf > @@ -27,12 +27,12 @@ [LibraryClasses] > DebugLib > MemoryAllocationLib > PrintLib > - QemuFwCfgLib > UefiBootServicesTableLib > > [Protocols] > gEfiDevicePathProtocolGuid > gEfiLoadedImageProtocolGuid > + gEfiSimpleFileSystemProtocolGuid > > [Guids] > gQemuKernelLoaderFsMediaGuid (3) The FileHandleLib class should be added, under [LibraryClasses]. > diff --git a/OvmfPkg/Library/GenericQemuLoadImageLib/GenericQemuLoadImageLib.c b/OvmfPkg/Library/GenericQemuLoadImageLib/GenericQemuLoadImageLib.c > index 114db7e8441f..f520456e3b24 100644 > --- a/OvmfPkg/Library/GenericQemuLoadImageLib/GenericQemuLoadImageLib.c > +++ b/OvmfPkg/Library/GenericQemuLoadImageLib/GenericQemuLoadImageLib.c > @@ -11,9 +11,9 @@ > #include > #include > #include > +#include > #include > #include > -#include > #include > #include > #include (4) The new "gEfiSimpleFileSystemProtocolGuid" dependency should be reflected here too, by adding: #include (In general the [Protocols] section of the INF file should be matched by #include directives.) This was masked from you because pulled in , but that's not enough justification for a difference between the INF [Protocols] section and the #include directive list. > @@ -30,6 +30,11 @@ typedef struct { > KERNEL_FILE_DEVPATH FileNode; > EFI_DEVICE_PATH_PROTOCOL EndNode; > } KERNEL_VENMEDIA_FILE_DEVPATH; > + > +typedef struct { > + VENDOR_DEVICE_PATH VenMediaNode; > + EFI_DEVICE_PATH_PROTOCOL EndNode; > +} SINGLE_VENMEDIA_NODE_DEVPATH; > #pragma pack () > > STATIC CONST KERNEL_VENMEDIA_FILE_DEVPATH mKernelDevicePath = { > @@ -51,6 +56,78 @@ STATIC CONST KERNEL_VENMEDIA_FILE_DEVPATH mKernelDevicePath = { > } > }; > > +STATIC CONST SINGLE_VENMEDIA_NODE_DEVPATH mQemuKernelLoaderFileSystemDevicePath = { (5) This variable name causes two overlong lines in the file; it should be renamed to "mQemuKernelLoaderFsDevicePath" please. > + { > + { > + MEDIA_DEVICE_PATH, MEDIA_VENDOR_DP, > + { sizeof (VENDOR_DEVICE_PATH) } > + }, > + QEMU_KERNEL_LOADER_FS_MEDIA_GUID > + }, { > + END_DEVICE_PATH_TYPE, END_ENTIRE_DEVICE_PATH_SUBTYPE, > + { sizeof (EFI_DEVICE_PATH_PROTOCOL) } > + } > +}; > + > +STATIC > +EFI_STATUS > +GetQemuKernelLoaderBlobSize ( > + IN EFI_FILE_HANDLE Root, > + IN CHAR16 *FileName, > + OUT UINTN *Size > + ) > +{ > + EFI_STATUS Status; > + EFI_FILE_HANDLE FileHandle; > + UINT64 FileSize; > + > + Status = Root->Open (Root, &FileHandle, FileName, EFI_FILE_MODE_READ, 0); > + if (EFI_ERROR (Status)) { > + return Status; > + } > + Status = FileHandleGetSize (FileHandle, &FileSize); > + if (EFI_ERROR (Status)) { > + goto CloseFile; > + } > + *Size = FileSize; (6) Silent truncation from UINT64 to UINTN, even if theoretical, is bad practice. Please do this: if (FileSize > MAX_UINTN) { Status = EFI_UNSUPPORTED; goto CloseFile; } *Size = (UINTN)FileSize; > + Status = EFI_SUCCESS; > +CloseFile: > + FileHandle->Close (FileHandle); > + return Status; > +} > + > +STATIC > +EFI_STATUS > +ReadWholeQemuKernelLoaderBlob ( > + IN EFI_FILE_HANDLE Root, > + IN CHAR16 *FileName, > + IN UINTN Size, > + OUT VOID *Buffer > + ) > +{ > + EFI_STATUS Status; > + EFI_FILE_HANDLE FileHandle; > + UINTN ReadSize; > + > + Status = Root->Open (Root, &FileHandle, FileName, EFI_FILE_MODE_READ, 0); > + if (EFI_ERROR (Status)) { > + return Status; > + } > + ReadSize = Size; > + Status = FileHandle->Read (FileHandle, &ReadSize, Buffer); > + if (EFI_ERROR (Status)) { > + goto CloseFile; > + } > + if (ReadSize != Size) { > + Status = EFI_PROTOCOL_ERROR; > + goto CloseFile; > + } > + Status = EFI_SUCCESS; > +CloseFile: > + FileHandle->Close (FileHandle); > + return Status; > +} > + > /** > Download the kernel, the initial ramdisk, and the kernel command line from > QEMU's fw_cfg. The kernel will be instructed via its command line to load > @@ -76,12 +153,16 @@ QemuLoadKernelImage ( > OUT EFI_HANDLE *ImageHandle > ) > { > - EFI_STATUS Status; > - EFI_HANDLE KernelImageHandle; > - EFI_LOADED_IMAGE_PROTOCOL *KernelLoadedImage; > - UINTN CommandLineSize; > - CHAR8 *CommandLine; > - UINTN InitrdSize; > + EFI_STATUS Status; > + EFI_HANDLE KernelImageHandle; > + EFI_LOADED_IMAGE_PROTOCOL *KernelLoadedImage; > + EFI_DEVICE_PATH_PROTOCOL *DevicePathNode; > + EFI_HANDLE FsVolumeHandle; > + EFI_SIMPLE_FILE_SYSTEM_PROTOCOL *FsProtocol; > + EFI_FILE_HANDLE Root; > + UINTN CommandLineSize; > + CHAR8 *CommandLine; > + UINTN InitrdSize; > > // > // Load the image. This should call back into the QEMU EFI loader file system. > @@ -124,8 +205,38 @@ QemuLoadKernelImage ( > ); > ASSERT_EFI_ERROR (Status); > > - QemuFwCfgSelectItem (QemuFwCfgItemCommandLineSize); > - CommandLineSize = (UINTN)QemuFwCfgRead32 (); > + // > + // Open the Qemu Kernel Loader abstract filesystem (volume) which will be > + // used to read the "initrd" and "cmdline" synthetic files. > + // (7) This comment is welcome, but it is inexact. We'll use the filesystem for reading the command line, yes, but regarding the initrd, we use the filesystem only for learning the *size* of the initrd. (And even the size of the initrd is only interesting inasmuch a nonzero size means that an initrd is *present*.) The initrd blob itself is not read by us. I suggest: used to query the "initrd" and to read the "cmdline" synthetic files. > + DevicePathNode = (EFI_DEVICE_PATH_PROTOCOL *)&mQemuKernelLoaderFileSystemDevicePath; > + Status = gBS->LocateDevicePath ( > + &gEfiSimpleFileSystemProtocolGuid, > + &DevicePathNode, > + &FsVolumeHandle > + ); > + if (EFI_ERROR (Status)) { > + return Status; (8) This leaks "KernelImageHandle". At this point, gBS->LoadImage() at the top of the function will have succeeded. Please jump to the UnloadImage label, rather than returning. > + } > + > + Status = gBS->HandleProtocol ( > + FsVolumeHandle, > + &gEfiSimpleFileSystemProtocolGuid, > + (VOID **)&FsProtocol > + ); > + if (EFI_ERROR (Status)) { > + return Status; (9) Same leak as described in (8); please jump to the UnloadImage label. > + } > + > + Status = FsProtocol->OpenVolume (FsVolumeHandle, &Root); > + if (EFI_ERROR (Status)) { > + return Status; (10) Same leak as described in (8); please jump to the UnloadImage label. > + } > + > + Status = GetQemuKernelLoaderBlobSize (Root, L"cmdline", &CommandLineSize); > + if (EFI_ERROR (Status)) { > + goto CloseRoot; > + } > > if (CommandLineSize == 0) { > KernelLoadedImage->LoadOptionsSize = 0; > @@ -136,8 +247,11 @@ QemuLoadKernelImage ( > goto UnloadImage; > } (11) Not fully shown in the context, but here we have: if (CommandLineSize == 0) { KernelLoadedImage->LoadOptionsSize = 0; } else { CommandLine = AllocatePool (CommandLineSize); if (CommandLine == NULL) { Status = EFI_OUT_OF_RESOURCES; goto UnloadImage; } Note that we have a "goto UnloadImage" in it. Please update that to "goto CloseRoot". > > - QemuFwCfgSelectItem (QemuFwCfgItemCommandLineData); > - QemuFwCfgReadBytes (CommandLineSize, CommandLine); > + Status = ReadWholeQemuKernelLoaderBlob (Root, L"cmdline", CommandLineSize, > + CommandLine); > + if (EFI_ERROR (Status)) { > + goto FreeCommandLine; > + } > > // > // Verify NUL-termination of the command line. > @@ -155,8 +269,10 @@ QemuLoadKernelImage ( > KernelLoadedImage->LoadOptionsSize = (UINT32)((CommandLineSize - 1) * 2); > } > > - QemuFwCfgSelectItem (QemuFwCfgItemInitrdSize); > - InitrdSize = (UINTN)QemuFwCfgRead32 (); > + Status = GetQemuKernelLoaderBlobSize (Root, L"initrd", &InitrdSize); > + if (EFI_ERROR (Status)) { > + goto FreeCommandLine; > + } > > if (InitrdSize > 0) { > // > @@ -193,6 +309,7 @@ QemuLoadKernelImage ( > } > > *ImageHandle = KernelImageHandle; > + Root->Close (Root); > return EFI_SUCCESS; > > FreeCommandLine: > @@ -201,6 +318,8 @@ FreeCommandLine: > } > UnloadImage: > gBS->UnloadImage (KernelImageHandle); > +CloseRoot: > + Root->Close (Root); > > return Status; > } > (12) So, the order of handlers is incorrect here, and when I looked into it, that was when I actually found preexistent issue (1). The desired epilogue for the function is: > *ImageHandle = KernelImageHandle; > Status = EFI_SUCCESS; > > FreeCommandLine: > if (CommandLineSize > 0) { > FreePool (CommandLine); > } > CloseRoot: > Root->Close (Root); > UnloadImage: > if (EFI_ERROR (Status)) { > gBS->UnloadImage (KernelImageHandle); > } > > return Status; The idea is that CommandLine and Root are both temporaries, and as such they need to be released on either success or failure. Whereas KernelImageHandle must be released precisely on failure. Furthermore, in either case, they must cascade as shown above -- in reverse order of construction. Thanks! Laszlo