Subject: [media-types] Request to register application/efi Media Type

From: "El-Haj-Mahmoud, Samer" <[email-masked]>
Date: Mon, 8 Feb 2016 21:37:18 +0000

Type name:
application

Subtype name:
efi

Required parameters: None

Optional parameters:
None

Encoding considerations:
binary

Security considerations:
EFI files contains native code that executes in the pre-boot environment at the firmware privilege. Extreme caution is advised.

EFI files support digital signatures providing strong integrity protection using UEFI Secure Boot. Basic checksums are also supported.

The EFI format does not provide any confidentiality protection of its own and requires external means if that is required.

The EFI format does not use compression.

EFI files allow for runtime generation of additional code.

Interoperability considerations:
EFI binaries follow the PE-COFF standard image format, and require a UEFI compliant firmware for proper execution. The EFI file format is also dependent on the target processor architecture.

Published specification:
http://www.microsoft.com/whdc/system/platform/firmware/PECOFF.mspx
http://www.uefi.org/sites/default/files/resources/UEFI%20Spec%202_6.pdf

Applications that use this media type:
EFI compliant firmware, boot loaders, and network boot programs (NBPs) utilizing UEFI HTTP Boot.

Fragment identifier considerations:
None

Additional information:
None

Deprecated alias names for this type:
None

Magic number(s):
MZ

File extension(s):
*.efi

Macintosh file type code(s):

Person & email address to contact for further information:
Samer El-Haj-Mahmoud , [email-masked]<mailto:[email-masked]>
UEFI Forum , [email-masked]<mailto:[email-masked]>

---

From: Mark Baker <[email-masked]>
Date: Wed, 10 Feb 2016 11:22:34 -0500

Hi Samer. This looks pretty good. Questions below...

On Mon, Feb 8, 2016 at 4:37 PM, El-Haj-Mahmoud, Samer
<[email-masked]> wrote:
> EFI binaries follow the PE-COFF standard image format, and require a UEFI
> compliant firmware for proper execution. The EFI file format is also
> dependent on the target processor architecture.

A quick look at that PDF spec seems to indicate a bytecode format is
used, so I'm wondering in what way the format is dependent on the
processor architecture? And if I'm misunderstanding, and if you can
save me some time skimming the spec, is the architecture indicated
within the format?

I also wonder if "efi" makes for a good type name. I have no knowledge
that it doesn't, but it is really short so there's a chance of a
collision or confusion. Looking at the application registry, I see
"edi" and "exi", but all three seem quite disjoint in purpose that
there probably won't be a problem. Ok then, just leaving this
paragraph hear to point out that I thought about it ;)

I note that the file extension is in use enough to be listed here;

http://www.file-extensions.org/efi-file-extension

and seems to align with this registration.

I'm curious; did you consider using "application/uefi"?

---

From: "El-Haj-Mahmoud, Samer" <[email-masked]>
Date: Wed, 10 Feb 2016 16:48:14 +0000

Mark,

Thanks for the feedback! I was beginning to wonder if my e-mail was received by the reflector.

The efi name is chosen over UEFI because of historical reasons. It dates back to the historical EFI (Extensible Firmware Interface) before the UEFI Forum was formed to promote the standard. Even today, the EFI nomenclature is the common pre-fix for most definitions in the UEFI Specification, as well as the common file extension used in the industry. I have not seen any API definitions that start with "UEFI_" or file extensions ".uefi". The MediaType need to be consistent with the industry usage.

UEFI applications (or executable images) can be compiled either natively (processor architecture dependent) or using the EFI Byte Code (EBC). Most UEFI compliant firmware support one native format (X64 on X64 machines, for instance) in addition to the processor-agnostic EBC format (using an EFI Byte Code interpreter that is carried in the firmware).

The format of the file (EBX, X64, etc..) is determined using the PE32+ image header on the file. The files themselves follow the Microsoft PE-COFF image format (and hence this efi MediaType proposal used that as a template: http://www.iana.org/assignments/media-types/application/vnd.microsoft.portable-executable ). Even though EFI files follow the Microsoft PECOFF Windows executable format, they are not executable under Windows, and can only be processed by a UEFI compliant firmware. The UEFI Forum controls the UEFI compliant firmware definitions and standard, hence the request of this to be a standard application/efi, and not use the Microsoft vendor for portable-executable.

The information of how to determine the image type are in both specifications:

	* UEFI 2.6 Specification, Section 2.1.1 
	* Microsoft Portable Executable and Common Object File Format Specification, version 8.3

I have copied the relent information here for easy reference. 

(From UEFI Specification, section 2.1.1):
~~~~~~~~~~~~~~~~~~~~~
The Machine value that is found in the PE image file header is used to indicate the machine code
type of the image. The machine code types for images with the UEFI image signature are defined
below. A given platform must implement the image type native to that platform and the image type
for EFI Byte Code (EBC). Support for other machine code types is optional to the platform.

// PE32+ Machine type for EFI images
#define EFI_IMAGE_MACHINE_IA32 		0x014c
#define EFI_IMAGE_MACHINE_IA64 		0x0200
#define EFI_IMAGE_MACHINE_EBC 		0x0EBC
#define EFI_IMAGE_MACHINE_x64 		0x8664
#define EFI_IMAGE_MACHINE_ARMTHUMB_MIXED 	0x01C2
#define EFI_IMAGE_MACHINE_AARCH64 		0xAA64

// PE32+ Subsystem type for EFI images
#define EFI_IMAGE_SUBSYSTEM_EFI_APPLICATION                     10
#define EFI_IMAGE_SUBSYSTEM_EFI_BOOT_SERVICE_DRIVER   11
#define EFI_IMAGE_SUBSYSTEM_EFI_RUNTIME_DRIVER             12

(From the PE-COFF Specification, sections 2.3 and 2.3.1)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 COFF File Header (Object and Image)
At the beginning of an object file, or immediately after the signature of an image file, is a standard COFF file header in the following format. Note that the Windows loader limits the number of sections to 96.

Offset	Size	Field	Description
  0	2	Machine	The number that identifies the type of target machine. For more information, see section 3.3.1, “Machine Types.”

Please let me know if you have any additional questions.

Thanks,
--Samer

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Mark Baker
Sent: Wednesday, February 10, 2016 10:23 AM
To: El-Haj-Mahmoud, Samer <[email-masked]>
Cc: [email-masked]
Subject: Re: [media-types] Request to register application/efi Media Type

On Mon, Feb 8, 2016 at 4:37 PM, El-Haj-Mahmoud, Samer <[email-masked]> wrote:
> EFI binaries follow the PE-COFF standard image format, and require a 
> UEFI compliant firmware for proper execution. The EFI file format is 
> also dependent on the target processor architecture.

A quick look at that PDF spec seems to indicate a bytecode format is used, so I'm wondering in what way the format is dependent on the processor architecture? And if I'm misunderstanding, and if you can save me some time skimming the spec, is the architecture indicated within the format?

I also wonder if "efi" makes for a good type name. I have no knowledge that it doesn't, but it is really short so there's a chance of a collision or confusion. Looking at the application registry, I see "edi" and "exi", but all three seem quite disjoint in purpose that there probably won't be a problem. Ok then, just leaving this paragraph hear to point out that I thought about it ;)

---

From: Mark Baker <[email-masked]>
Date: Wed, 10 Feb 2016 14:16:32 -0500

Thanks so much for the detailed response. That addresses all of my concerns.

---

From: "El-Haj-Mahmoud, Samer" <[email-masked]>
Date: Fri, 12 Feb 2016 17:32:48 +0000

Thank you.

What should be the next step in this submission?

---

From: Mark Baker <[email-masked]>
Date: Mon, 15 Feb 2016 23:05:26 -0500

> What should be the next step in this submission?

Per RFC 6838, since this is a standards tree registration from a
separate standards body, you need to make a request to the IESG on
behalf of UEFI.

---

From: "El-Haj-Mahmoud, Samer" <[email-masked]>
Date: Tue, 16 Feb 2016 20:02:51 +0000

Thanks Mark. I have sent the request to [email-masked]

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Mark Baker
Sent: Monday, February 15, 2016 10:05 PM
To: El-Haj-Mahmoud, Samer <[email-masked]>
Cc: [email-masked]
Subject: Re: [media-types] Request to register application/efi Media Type

> What should be the next step in this submission?

Per RFC 6838, since this is a standards tree registration from a separate standards body, you need to make a request to the IESG on behalf of UEFI.