From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-1.mimecast.com (us-smtp-1.mimecast.com [207.211.31.120]) by mx.groups.io with SMTP id smtpd.web11.12165.1586874375051174302 for ; Tue, 14 Apr 2020 07:26:15 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=HaaTh2UF; spf=pass (domain: redhat.com, ip: 207.211.31.120, mailfrom: lersek@redhat.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1586874374; 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=mwYZjYKMed9QmIWiVf1ikP4hUbG2nKYYQC4ojiA44JY=; b=HaaTh2UFnyHEsxMwKyEhmt8OgWFfE4AEITvA71ycKHGlAfVgqfPeOByt9X969l98de5x5N n1Rhxwy8FHqlxQJanZOQCpWOfbXZ1Jf4x5pckJkasSR+vF66Ae1lPfVLwMeOGI/TSzwJIL mrrCgFkfkbzZbCxlClM8Qj2rKkCw6Yg= 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-171-QoY34fjgP2yiB1GKcf41MQ-1; Tue, 14 Apr 2020 10:26:04 -0400 X-MC-Unique: QoY34fjgP2yiB1GKcf41MQ-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 2C5E310CE781; Tue, 14 Apr 2020 14:26:08 +0000 (UTC) Received: from lacos-laptop-7.usersys.redhat.com (ovpn-113-193.ams2.redhat.com [10.36.113.193]) by smtp.corp.redhat.com (Postfix) with ESMTP id 4CF0B5C1BE; Tue, 14 Apr 2020 14:26:02 +0000 (UTC) Subject: Re: [edk2-discuss] Load Option passing. Either bugs or my confusion. To: vlrzprgts@gmail.com References: <18709.1586743215734342129@groups.io> <11181.1586825080096843656@groups.io> Cc: discuss@edk2.groups.io, edk2-devel-groups-io From: "Laszlo Ersek" Message-ID: <623b1855-285c-cce3-c806-c17e5fd217ea@redhat.com> Date: Tue, 14 Apr 2020 16:26:01 +0200 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: <11181.1586825080096843656@groups.io> X-Scanned-By: MIMEDefang 2.79 on 10.5.11.16 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 04/14/20 02:44, valerij zaporogeci wrote: > 1. what this pointer (OS Loader > ImageHandle)->(LOADED_IMAGE_PROTOCOL)->LoadOptions points to? According to the UEFI spec , section "9.1 EFI Loaded Image Protocol": LoadOptionsSize The size in bytes of LoadOptions. LoadOptions A pointer to the image's binary load options. [...] Each loaded image has an image handle that supports EFI_LOADED_IMAGE_PROTOCOL. When an image is started, it is passed the image handle for itself. The image can use the handle to obtain its relevant image data stored in the EFI_LOADED_IMAGE_PROTOCOL structure, such as its load options. And from section "7.4 Image Services", near the LoadImage() boot service: Once the image is loaded, firmware creates and returns an EFI_HANDLE that identifies the image and supports EFI_LOADED_IMAGE_PROTOCOL and the EFI_LOADED_IMAGE_DEVICE_PATH_PROTOCOL. The caller may fill in the image's "load options" data, or add additional protocol support to the handle. So an agent calls the LoadImage() boot service to load the image. Then it looks up the EFI_LOADED_IMAGE_PROTOCOL instance on the handle that was output by LoadImage(). The agent populates LoadOptionsSize and LoadOptions in said EFI_LOADED_IMAGE_PROTOCOL instance, and then calls StartImage(). The started image can then consume LoadOptionsSize and LoadOptions. I think you mistook these fields for describing an EFI_LOAD_OPTION structure (from section "3.1.3 Load Options"). EFI_LOAD_OPTION is a different thing -- the EFI_LOADED_IMAGE_PROTOCOL.LoadOptions field points to a binary blob whose interpretation is specific to the image being started. Its internals are not regulated by the spec. More below: > > if it points to the Load Option Descriptor, then on OVMF it doesn't, > since it points to only OptionalData[]. > if it was meant to point to OptionalData[], then: > > 1. how does an OS Loader get _its_ Load Option FilePathList[]? ALL > elements. > and Again, EFI_LOADED_IMAGE_PROTOCOL.LoadOptions does not point to an EFI_LOAD_OPTION structure. Still, your question #1 makes sense; indeed an OS boot loader (or another UEFI app) is "entitled" to see the UEFI device path from which it was loaded from. The passage I quoted above already mentions EFI_LOADED_IMAGE_DEVICE_PATH_PROTOCOL. It is specified in detail in section "9.2 EFI Loaded Image Device Path Protocol". Excerpt: The Loaded Image Device Path Protocol must be installed onto the image handle of a PE/COFF image loaded through the EFI Boot Service LoadImage(). A copy of the device path specified by the DevicePath parameter to the EFI Boot Service LoadImage() is made before it is installed onto the image handle. It is legal to call LoadImage() for a buffer in memory with a NULL DevicePath parameter. In this case, the Loaded Image Device Path Protocol is installed with a NULL interface pointer. Summary: - Passing arguments to a UEFI image: locate EFI_LOADED_IMAGE_PROTOCOL on the image handle, and populate the LoadOptions / LoadOptionsSize members. The "arguments" are a binary blob, only defined by the receiving application. - Finding where a UEFI image was loaded from: locate EFI_LOADED_IMAGE_DEVICE_PATH_PROTOCOL on the image handle. - Regarding "EFI_LOAD_OPTION.OptionalData": in case you boot a Boot#### option, it is "EFI_LOAD_OPTION.OptionalData" that will be passed to the image in "EFI_LOADED_IMAGE_PROTOCOL.LoadOptions". More below: > 2. should FilePathList[] be a multiinstance Device Path (ending with > type 7F, subtype 1, except the last), or every element should end with > {7F, FF}? I cannot answer this. The spec writes, about "FilePathList": A packed array of UEFI device paths. The first element of the array is a device path that describes the device and location of the Image for this load option. The FilePathList[0] is specific to the device type. Other device paths may optionally exist in the FilePathList, but their usage is OSV specific. Each element in the array is variable length, and ends at the device path end structure. Because the size of Description is arbitrary, this data structure is not guaranteed to be aligned on a natural boundary. This data structure may have to be copied to an aligned natural boundary before it is used. I'm not sure if the "non-first" elements in this array are supposed to be 2nd and later devpath instances in a single multi-instance device path, or if they are entirely separate (themselves single or multi-instance) device paths. Either way, I don't think those "elements" are passed to the loaded image in any direct way. You could perhaps get back at the EFI_LOAD_OPTION once the loaded image is running with the help of the "BootCurrent" standard UEFI variable. Thanks Laszlo