From nobody Mon Feb 9 12:25:20 2026 Delivered-To: importer@patchew.org Received-SPF: pass (zoho.com: domain of groups.io designates 66.175.222.12 as permitted sender) client-ip=66.175.222.12; envelope-from=bounce+27952+46766+1787277+3901457@groups.io; helo=web01.groups.io; Authentication-Results: mx.zohomail.com; dkim=pass; spf=pass (zoho.com: domain of groups.io designates 66.175.222.12 as permitted sender) smtp.mailfrom=bounce+27952+46766+1787277+3901457@groups.io; dmarc=fail(p=none dis=none) header.from=intel.com ARC-Seal: i=1; a=rsa-sha256; t=1567585569; cv=none; d=zoho.com; s=zohoarc; b=nCdBkFU9A1wkkOJyDpUGEr6wtDb2iSeZuVOA6WDNNrWUBdXZEUUy+gTe3DWF3qbFV3I41j7snWWz9RbbJ0ZjzyI8NAr3y+a6I6JdiMyp7z05rdSga99LsbfXIXqeLLduK2GBAkIwDQj4ItM1vrZMCrihs2GuaCtCTBNCj2lxMsc= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zoho.com; s=zohoarc; t=1567585569; h=Cc:Date:From:In-Reply-To:List-Id:List-Unsubscribe:Message-ID:Reply-To:References:Sender:Subject:To:ARC-Authentication-Results; bh=6mnslXxWIlzVJq0n1M92p9L7sBwthUne6U3jVNUbm+Q=; b=CK949hTInIsajw+a0IUxmv6cM83ZEa8ALOgJkY2PaqTCxQzBsbAcDKhDjCtiEwtJ1X+vZemDx/PIWxh7zVr9rbWFJSjGKZ7n839hSUzkSHeEw44ktekYLi9Sho4f9mFvCF/SmRFSWJm+Oc3wqyuMJpBt5OCCshROQI3yhPKw4eM= ARC-Authentication-Results: i=1; mx.zoho.com; dkim=pass; spf=pass (zoho.com: domain of groups.io designates 66.175.222.12 as permitted sender) smtp.mailfrom=bounce+27952+46766+1787277+3901457@groups.io; dmarc=fail header.from= (p=none dis=none) header.from= Received: from web01.groups.io (web01.groups.io [66.175.222.12]) by mx.zohomail.com with SMTPS id 1567585569798542.6915035316409; Wed, 4 Sep 2019 01:26:09 -0700 (PDT) Return-Path: X-Received: from mga02.intel.com (mga02.intel.com [134.134.136.20]) by groups.io with SMTP; Wed, 04 Sep 2019 01:26:09 -0700 X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False X-Received: from orsmga006.jf.intel.com ([10.7.209.51]) by orsmga101.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 04 Sep 2019 01:26:08 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.64,465,1559545200"; d="scan'208";a="187549163" X-Received: from shwdeopenpsi114.ccr.corp.intel.com ([10.239.157.147]) by orsmga006.jf.intel.com with ESMTP; 04 Sep 2019 01:26:06 -0700 From: "Dandan Bi" To: devel@edk2.groups.io Cc: Leif Lindholm , Ard Biesheuvel , Laszlo Ersek Subject: [edk2-devel] [patch 1/3] EmbeddedPkg: Unload image on EFI_SECURITY_VIOLATION Date: Wed, 4 Sep 2019 16:25:53 +0800 Message-Id: <20190904082555.35424-2-dandan.bi@intel.com> In-Reply-To: <20190904082555.35424-1-dandan.bi@intel.com> References: <20190904082555.35424-1-dandan.bi@intel.com> Precedence: Bulk List-Unsubscribe: Sender: devel@edk2.groups.io List-Id: Mailing-List: list devel@edk2.groups.io; contact devel+owner@edk2.groups.io Reply-To: devel@edk2.groups.io,dandan.bi@intel.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=groups.io; q=dns/txt; s=20140610; t=1567585569; bh=fXdHuJtQveNuPD6jyBX03jvvSSrybAoda7TIWZuuaUY=; h=Cc:Date:From:Reply-To:Subject:To; b=RPGs4WHGUEi3GCTHk/ut6wU3aHmIu8R+jUiC1oig4zqPBxDTCoJZ0ePCdSHHgQAucmZ hHKSIASy+okR+eRGajRXEN6hgNgGxE8cQw8kN0SaVRaNQoAy+Ht6iG7rlCNOq5k51AEXf gjiAUczygN0bAFmC2A4JPBqNphkDwHchGDw= X-ZohoMail-DKIM: pass (identity @groups.io) Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" For the LoadImage() boot service, with EFI_SECURITY_VIOLATION retval, the Image was loaded and an ImageHandle was created with a valid EFI_LOADED_IMAGE_PROTOCOL, but the image can not be started right now. This follows UEFI Spec. But if the caller of LoadImage() doesn't have the option to defer the execution of an image, we can not treat EFI_SECURITY_VIOLATION like any other LoadImage() error, we should unload image for the EFI_SECURITY_VIOLATION to avoid resource leak. This patch is to do error handling for EFI_SECURITY_VIOLATION explicitly for the callers in EmbeddedPkg which don't have the policy to defer the execution of the image. Cc: Leif Lindholm Cc: Ard Biesheuvel Cc: Laszlo Ersek REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3D1992 Signed-off-by: Dandan Bi Acked-by: Ard Biesheuvel Acked-by: Laszlo Ersek --- .../AndroidFastboot/Arm/BootAndroidBootImg.c | 9 +++++++++ .../Library/AndroidBootImgLib/AndroidBootImgLib.c | 12 ++++++++++++ 2 files changed, 21 insertions(+) diff --git a/EmbeddedPkg/Application/AndroidFastboot/Arm/BootAndroidBootImg= .c b/EmbeddedPkg/Application/AndroidFastboot/Arm/BootAndroidBootImg.c index 591afbe7cc..9fa28e3390 100644 --- a/EmbeddedPkg/Application/AndroidFastboot/Arm/BootAndroidBootImg.c +++ b/EmbeddedPkg/Application/AndroidFastboot/Arm/BootAndroidBootImg.c @@ -71,10 +71,19 @@ StartEfiApplication ( =20 // Load the image from the device path with Boot Services function Status =3D gBS->LoadImage (TRUE, ParentImageHandle, DevicePath, NULL, 0, &ImageHandle); if (EFI_ERROR (Status)) { + // + // With EFI_SECURITY_VIOLATION retval, the Image was loaded and an Ima= geHandle was created + // with a valid EFI_LOADED_IMAGE_PROTOCOL, but the image can not be st= arted right now. + // If the caller doesn't have the option to defer the execution of an = image, we should + // unload image for the EFI_SECURITY_VIOLATION to avoid resource leak. + // + if (Status =3D=3D EFI_SECURITY_VIOLATION) { + gBS->UnloadImage (ImageHandle); + } return Status; } =20 // Passed LoadOptions to the EFI Application if (LoadOptionsSize !=3D 0) { diff --git a/EmbeddedPkg/Library/AndroidBootImgLib/AndroidBootImgLib.c b/Em= beddedPkg/Library/AndroidBootImgLib/AndroidBootImgLib.c index d9e7aa7d2b..2e9e74db1d 100644 --- a/EmbeddedPkg/Library/AndroidBootImgLib/AndroidBootImgLib.c +++ b/EmbeddedPkg/Library/AndroidBootImgLib/AndroidBootImgLib.c @@ -439,10 +439,22 @@ AndroidBootImgBoot ( + KernelSize; =20 Status =3D gBS->LoadImage (TRUE, gImageHandle, (EFI_DEVICE_PATH *)&KernelDevicePath, (VOID*)(UINTN)Kernel, KernelSize, &ImageHandle); + if (EFI_ERROR (Status)) { + // + // With EFI_SECURITY_VIOLATION retval, the Image was loaded and an Ima= geHandle was created + // with a valid EFI_LOADED_IMAGE_PROTOCOL, but the image can not be st= arted right now. + // If the caller doesn't have the option to defer the execution of an = image, we should + // unload image for the EFI_SECURITY_VIOLATION to avoid resource leak. + // + if (Status =3D=3D EFI_SECURITY_VIOLATION) { + gBS->UnloadImage (ImageHandle); + } + return Status; + } =20 // Set kernel arguments Status =3D gBS->HandleProtocol (ImageHandle, &gEfiLoadedImageProtocolGui= d, (VOID **) &ImageInfo); ImageInfo->LoadOptions =3D NewKernelArg; --=20 2.18.0.windows.1 -=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#46766): https://edk2.groups.io/g/devel/message/46766 Mute This Topic: https://groups.io/mt/33136045/1787277 Group Owner: devel+owner@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [importer@patchew.org] -=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-