From nobody Sat May 4 04:50:30 2024 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+46710+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+46710+1787277+3901457@groups.io; dmarc=fail(p=none dis=none) header.from=redhat.com ARC-Seal: i=1; a=rsa-sha256; t=1567528686; cv=none; d=zoho.com; s=zohoarc; b=JIoRkrP4WADcqoQDOFDLxKpmzqyYh4kMXtRpMIKFEfANW9f6MqwR7K4WSgNP7hqzEEuCPPO8ziKuOIjCdWvBk9P5oT0zA+Hcn6rpRtbtIxBTxFReMEGvWAvhbP+988iZMpO23ExIN6cTPNQcrSe4ZYfsva4OqufBU09DKCByKl4= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zoho.com; s=zohoarc; t=1567528686; h=Content-Transfer-Encoding:Cc:Date:From:List-Id:List-Unsubscribe:MIME-Version:Message-ID:Reply-To:Sender:Subject:To:ARC-Authentication-Results; bh=zVYDw2cQPaHa1sHLjw84cubi3aPCLSluVaKszPsbqtg=; b=INeZTtZXJSMesN/yxVI/PXGe9OYMzKxQo/FA++3UIYUw5hdXF4jyAaqiGrpoVKQ5OJdhuJiirDET6qZsjQ81GpC2nfEraMhc9BSsYCnisyADq8buBah+kSC8PEkdJJxZ6R7NMubNFDvH4Jf1G17iRPc/8JsFEoiE+Jr1U1Oz128= 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+46710+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 1567528686176830.3240805888033; Tue, 3 Sep 2019 09:38:06 -0700 (PDT) Return-Path: X-Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by groups.io with SMTP; Tue, 03 Sep 2019 09:38:05 -0700 X-Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.phx2.redhat.com [10.5.11.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 7A9003082128; Tue, 3 Sep 2019 16:38:04 +0000 (UTC) X-Received: from lacos-laptop-7.usersys.redhat.com (ovpn-116-140.ams2.redhat.com [10.36.116.140]) by smtp.corp.redhat.com (Postfix) with ESMTP id 558695DD6D; Tue, 3 Sep 2019 16:38:03 +0000 (UTC) From: "Laszlo Ersek" To: edk2-devel-groups-io Cc: Ard Biesheuvel , Dandan Bi , Leif Lindholm Subject: [edk2-devel] [PATCH] ArmVirtPkg/PlatformBootManagerLib: unload image on EFI_SECURITY_VIOLATION Date: Tue, 3 Sep 2019 18:38:01 +0200 Message-Id: <20190903163801.28652-1-lersek@redhat.com> MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.79 on 10.5.11.14 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.42]); Tue, 03 Sep 2019 16:38:04 +0000 (UTC) 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,lersek@redhat.com Content-Transfer-Encoding: quoted-printable DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=groups.io; q=dns/txt; s=20140610; t=1567528685; bh=rH5ZBnj5lDB8AWk5jHTwVSVjw7J6mm5Zb6erxMP979Y=; h=Cc:Date:From:Reply-To:Subject:To; b=mtzRz/YKeuIDtG2jI5v7eJU3MW3jJKCocuv4dJ0U6G2UwABke3ukO7VmHC9WY4Macrs ObJSpokio68ZPpkWykq89wMsESw2rJyXvCwWMIEAKmFmnAskslTGAaq7AN6NwvxUHwIdi S2r4IGY6INrsNTz3xp4SmhWm77RwgAP+Hd0= X-ZohoMail-DKIM: pass (identity @groups.io) Content-Type: text/plain; charset="utf-8" The LoadImage() boot service is a bit unusual in that it allocates resources in a particular failure case; namely, it produces a valid "ImageHandle" when it returns EFI_SECURITY_VIOLATION. This is supposed to happen e.g. when Secure Boot verification fails for the image, but the platform policy for the particular image origin (such as "fixed media" or "removable media") is DEFER_EXECUTE_ON_SECURITY_VIOLATION. The return code allows platform logic to selectively override the verification failure, and launch the image nonetheless. ArmVirtPkg/PlatformBootManagerLib does not override EFI_SECURITY_VIOLATION for the kernel image loaded from fw_cfg -- any LoadImage() error is considered fatal. When we simply treat EFI_SECURITY_VIOLATION like any other LoadImage() error, we leak the resources associated with "KernelImageHandle". From a resource usage perspective, EFI_SECURITY_VIOLATION must be considered "success", and rolled back. Implement this rollback, without breaking the proper "nesting" of error handling jumps and labels. Cc: Ard Biesheuvel Cc: Dandan Bi Cc: Leif Lindholm Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=3D1992 Fixes: 23d04b58e27b382bbd3f9b16ba9adb1cb203dad5 Signed-off-by: Laszlo Ersek Acked-by: Ard Biesheuvel Reviewed-by: Dandan Bi Reviewed-by: Philippe Mathieu-Daude --- Notes: Repo: https://github.com/lersek/edk2.git Branch: ldimg_armvirt_bz1992 ArmVirtPkg/Library/PlatformBootManagerLib/QemuKernel.c | 9 ++++++++- 1 file changed, 8 insertions(+), 1 deletion(-) diff --git a/ArmVirtPkg/Library/PlatformBootManagerLib/QemuKernel.c b/ArmVi= rtPkg/Library/PlatformBootManagerLib/QemuKernel.c index 3cc83e3b7b95..d3851fd75fa5 100644 --- a/ArmVirtPkg/Library/PlatformBootManagerLib/QemuKernel.c +++ b/ArmVirtPkg/Library/PlatformBootManagerLib/QemuKernel.c @@ -968,53 +968,60 @@ TryRunningQemuKernel ( =20 // // Create a device path for the kernel image to be loaded from that will= call // back into our file system. // KernelDevicePath =3D FileDevicePath (FileSystemHandle, KernelBlob->Name); if (KernelDevicePath =3D=3D NULL) { DEBUG ((EFI_D_ERROR, "%a: failed to allocate kernel device path\n", __FUNCTION__)); Status =3D EFI_OUT_OF_RESOURCES; goto UninstallProtocols; } =20 // // Load the image. This should call back into our file system. // Status =3D gBS->LoadImage ( FALSE, // BootPolicy: exact match required gImageHandle, // ParentImageHandle KernelDevicePath, NULL, // SourceBuffer 0, // SourceSize &KernelImageHandle ); if (EFI_ERROR (Status)) { DEBUG ((EFI_D_ERROR, "%a: LoadImage(): %r\n", __FUNCTION__, Status)); - goto FreeKernelDevicePath; + if (Status !=3D EFI_SECURITY_VIOLATION) { + goto FreeKernelDevicePath; + } + // + // From the resource allocation perspective, EFI_SECURITY_VIOLATION me= ans + // "success", so we must roll back the image loading. + // + goto UnloadKernelImage; } =20 // // Construct the kernel command line. // Status =3D gBS->OpenProtocol ( KernelImageHandle, &gEfiLoadedImageProtocolGuid, (VOID **)&KernelLoadedImage, gImageHandle, // AgentHandle NULL, // ControllerHandle EFI_OPEN_PROTOCOL_GET_PROTOCOL ); ASSERT_EFI_ERROR (Status); =20 if (CommandLineBlob->Data =3D=3D NULL) { KernelLoadedImage->LoadOptionsSize =3D 0; } else { // // Verify NUL-termination of the command line. // if (CommandLineBlob->Data[CommandLineBlob->Size - 1] !=3D '\0') { DEBUG ((EFI_D_ERROR, "%a: kernel command line is not NUL-terminated\= n", __FUNCTION__)); Status =3D EFI_PROTOCOL_ERROR; goto UnloadKernelImage; --=20 2.19.1.3.g30247aa5d201 -=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 (#46710): https://edk2.groups.io/g/devel/message/46710 Mute This Topic: https://groups.io/mt/33128626/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-