From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-1.mimecast.com (us-smtp-1.mimecast.com [205.139.110.120]) by mx.groups.io with SMTP id smtpd.web11.2284.1583234442960062620 for ; Tue, 03 Mar 2020 03:20:43 -0800 Authentication-Results: mx.groups.io; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=OWW6hfYz; spf=pass (domain: redhat.com, ip: 205.139.110.120, mailfrom: lersek@redhat.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1583234442; 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=ZHxm3YeAhhiih2+DZpI48KLUpast6SbidfcV7ugYO4k=; b=OWW6hfYzmrWHMB5uFGraurvs3VKdnV5hT2u8ryuofg2KdBvKdqKaicUwK2yoIGXDX6Orgq mP0OxCQIVi4EjAcfw5xTtvFl2HcC1aXKq50mPvC6dQOtpcIGatF7v5K0tvU1kFf7FQsfMg vu3TxVot+YE4lC9f1qJh1VU6C8x5chQ= 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-420-R7Z_LgbJPT-hTQY6Vzci4g-1; Tue, 03 Mar 2020 06:20:40 -0500 X-MC-Unique: R7Z_LgbJPT-hTQY6Vzci4g-1 Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 5B40D107ACC4; Tue, 3 Mar 2020 11:20:39 +0000 (UTC) Received: from lacos-laptop-7.usersys.redhat.com (ovpn-117-34.ams2.redhat.com [10.36.117.34]) by smtp.corp.redhat.com (Postfix) with ESMTP id C01328D568; Tue, 3 Mar 2020 11:20:38 +0000 (UTC) Subject: Re: [edk2-devel] [PATCH 09/13] OvmfPkg: implement QEMU loader library for X86 with legacy fallback To: Ard Biesheuvel Cc: edk2-devel-groups-io References: <20200302072936.29221-1-ard.biesheuvel@linaro.org> <20200302072936.29221-10-ard.biesheuvel@linaro.org> <8519f487-c6cf-48e8-3555-4c06ab12373e@redhat.com> From: "Laszlo Ersek" Message-ID: Date: Tue, 3 Mar 2020 12:20:37 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: X-Scanned-By: MIMEDefang 2.79 on 10.5.11.11 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Language: en-US Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit On 03/03/20 11:08, Ard Biesheuvel wrote: > On Tue, 3 Mar 2020 at 10:45, Laszlo Ersek wrote: >> (13) I'm worried that we are installing custom protocols on a handle >> that was first created by LoadImage(), before we pass it to >> UnloadImage(). I don't know if, per spec, LoadImage() / UnloadImage() >> are allowed to associate such information with the specific image handle >> that is *beyond* the protocol interfaces visible on the handle. >> > > I'm not sure I follow. Why would it not be allowed to install > additional protocols on that handle? Note that it is rather common for > drivers to install arbitrary protocols on the handle that they receive > via the PE/COFF entry point. Yes, that's correct; however what doesn't happen is that protocols installed on the image handle *survive* unloading the image with gBS->UnloadImage(). Put differently, if the image handle was created by LoadImage() -- by virtue of LoadImage() installing the first protocol interface --, then I *think* there might be a silent expectation that UnloadImage() will also uninstall the last protocol interface, thereby releasing the image handle itself. >> Can we modify the logic somehow so that we don't have to silently call >> QemuLoadLegacyImage() inside QemuStartKernelImage()? If not, we should >> at least document that this is arguably a grey area per UEFI spec. >> > > That would require QemuStartImage() to take a EFI_HANDLE* rather than > a EFI_HANDLE, Yes, I agree. > which is what I was trying to avoid here. I perceive this as a lifecycle risk / grey area in the spec. If we can make it disappear by having QemuStartImage() take an "IN OUT EFI_HANDLE*", IMO that's a significant improvement, and hopefully not much additional complexity. I think the underlying use case is intricate enough for us to let it affect the abstract QemuStartKernelImage() interface. Thanks! Laszlo