Protocols
The extensible nature of UEFI is built around protocols. UEFI Drv are sometimes confused with UEFI protocols. Although they are closely related, they are distinctly different
UEFI Driver is executable the UEFI Image installs variety of protocols have various handles to accomplish
its job.
[+] UEFI Protocol : is block function pointers and data structure api have been defined by specification minimum the specification must define a (GUID).
This number is the protocols real name boot service like LocateProtocol
uses this number to find his protocol in the handle database.
sometimes protocol often includes a set of procedures and/or data structures, called The following code sequence is an example of a protocol definition. Notice how it defines two function definitions and one
data field.
example of protocol definition
Protocol Interface Structure
shows a single handle and protocol from the handle database that is produced by a UEFI driver.
The protocol is composed of a GUID and a protocol interface structure.
Many times the UEFI driver that produces a protocol interface maintains additional private data fields.
The protocolinterface structure itself simply contains pointers to the protocol function.
The protocol functions are actually contained within the UEFI driver.
A UEFI driver might produce one protocol or many protocols depending on the drivers complexity.
Not all protocols are defined in the UEFI
the UEFI Developer KIt(EDK) give a includes many protocols and that not part of uefi Specification
These protocols provide the wider range of functionality that might be needed in any particular implementation, but they are not defined in the
UEFI Specification because they do not present an external interface that is required to support booting an OS or writing a UEFI driver. The creation of
new protocols is how UEFI-based systems can be extended over time as new devices, buses, and technologies are introduced. For example, some protocols
The OS loader and drivers should not depend on these types of protocols because they are not guaranteed to be present in every UEFI-compliant system.
OS loaders and drivers should depend only on protocols that are defined in the UEFI Specification and protocols that are required by platform design.
The extensible nature of UEFI allows the developers of each platform to design and add special protocols. Using these protocols, they can expand the
capabilities of UEFI and provide access to proprietary devices and interfaces in Because a protocol is “named” by a GUID, no other protocols should have
that same identification number.
Care must be taken when creating a new protocol to define a new GUID for it. UEFI fundamentally assumes that acongruity with the rest of the UEFI architecture.
specific GUID exposes a specific protocol interface.
Cutting and pasting an existing GUID or hand-modifying an existing GUID creates the opportunity for a duplicate GUID to be introduced
A system containing a duplicate GUID
inadvertently could find the new protocol and think that it is another protocol, crashing the system as a result. For these types of bugs, finding the root cause is also very difficult. The GUID allows for naming APIs without having to
worry about namespace collision. In systems such as PC/AT BIOS, services were added as an enumeration. For example, the venerable Int15h interface
would pass the service type in AX. Since no central repository or specification managed the evolution of Int15h services, several vendors defined similar
service numbers, thus making interoperability with operating systems and preOS applications difficult. Through the judicious use of GUIDs to name APIs
and an association to develop the specification, UEFI balances the need for API evolution with interoperability
Working with Protocols
Working with Protocols
Any UEFI code can operate with protocols during boot time.
However after ExitBootServices(); is called,, the handle database is no longer available.
Several UEFI boot time services work with UEFI protocols.
Multiple Protocol Instances
A handle may have many protocols attached to it. However, it may have only one protocol of each type. In other words, a handle may not have more than one instance of the exact same protocol. Otherwise, it would make requests for a particular protocol on a handle nondeterministic.
However, drivers may create multiple instances of a particular protocol and attach each instance to a different handle. The PCI I/O Protocol fits this scenario, where the PCI bus driver installs a PCI I/O Protocol instance for each PCI device. Each instance of the PCI I/O Protocol is configured with data values that are unique to that PCI device, including the location and size of the UEFI Option ROM (OpROM) image.
Also, each driver can install customized versions of the same protocol as long as they do not use the same handle. For example, each UEFI driver
installs the Component Name Protocol on its driver image handle, yet when the EFI_COMPONENT_NAME2_PROTOCOL::GetDriverName() function is called, each handle returns the unique name of the driver that
owns that image handle.
The EFI_COMPONENT_NAME2_PROTOCOL::GetDriverName() function on the USB bus driver handle returns "USB bus driver", but on the PXE driver handle it returns "PXE base code driver"
The extensible nature of UEFI is built around protocols. UEFI Drv are sometimes confused with UEFI protocols. Although they are closely related, they are distinctly different
UEFI Driver is executable the UEFI Image installs variety of protocols have various handles to accomplish
its job.
[+] UEFI Protocol : is block function pointers and data structure api have been defined by specification minimum the specification must define a (GUID).
This number is the protocols real name boot service like LocateProtocol
C++:
mBootScriptSave = 0;
Status = BS->LocateProtocol (&save, NULL, (VOID **)&mBootScriptSave);sometimes protocol often includes a set of procedures and/or data structures, called The following code sequence is an example of a protocol definition. Notice how it defines two function definitions and one
data field.
example of protocol definition
C++:
#define EFI_COMPONENT_NAME2_PROTOCOL_GUID \
{0x6a7a5cff, 0xe8d9, 0x4f70, { 0xba, 0xda, 0x75, 0xab, 0x30, 0x25, 0xce, 0x14 } } // global id for name protocol
typedef struct _EFI_COMPONENT_NAME2_PROTOCOL EFI_COMPONENT_NAME2_PROTOCOL;Protocol Interface Structure
C++:
typedef struct _EFI_COMPONENT_NAME2_PROTOCOL {
[input] EFI_COMPONENT_NAME_GET_DRIVER_NAME GetDriverName; // get driver name
EFI_COMPONENT_NAME_GET_CONTROLLER_NAME GetControllerName;//get controller name
CHAR8 *SupportedLanguages; //List of supported languages, this protocol is RFC 4646
} EFI_COMPONENT_NAME2_PROTOCOL;shows a single handle and protocol from the handle database that is produced by a UEFI driver.
The protocol is composed of a GUID and a protocol interface structure.
Many times the UEFI driver that produces a protocol interface maintains additional private data fields.
The protocolinterface structure itself simply contains pointers to the protocol function.
The protocol functions are actually contained within the UEFI driver.
A UEFI driver might produce one protocol or many protocols depending on the drivers complexity.
Not all protocols are defined in the UEFI
the UEFI Developer KIt(EDK) give a includes many protocols and that not part of uefi Specification
These protocols provide the wider range of functionality that might be needed in any particular implementation, but they are not defined in the
UEFI Specification because they do not present an external interface that is required to support booting an OS or writing a UEFI driver. The creation of
new protocols is how UEFI-based systems can be extended over time as new devices, buses, and technologies are introduced. For example, some protocols
The OS loader and drivers should not depend on these types of protocols because they are not guaranteed to be present in every UEFI-compliant system.
OS loaders and drivers should depend only on protocols that are defined in the UEFI Specification and protocols that are required by platform design.
The extensible nature of UEFI allows the developers of each platform to design and add special protocols. Using these protocols, they can expand the
capabilities of UEFI and provide access to proprietary devices and interfaces in Because a protocol is “named” by a GUID, no other protocols should have
that same identification number.
Care must be taken when creating a new protocol to define a new GUID for it. UEFI fundamentally assumes that acongruity with the rest of the UEFI architecture.
specific GUID exposes a specific protocol interface.
Cutting and pasting an existing GUID or hand-modifying an existing GUID creates the opportunity for a duplicate GUID to be introduced
A system containing a duplicate GUID
inadvertently could find the new protocol and think that it is another protocol, crashing the system as a result. For these types of bugs, finding the root cause is also very difficult. The GUID allows for naming APIs without having to
worry about namespace collision. In systems such as PC/AT BIOS, services were added as an enumeration. For example, the venerable Int15h interface
would pass the service type in AX. Since no central repository or specification managed the evolution of Int15h services, several vendors defined similar
service numbers, thus making interoperability with operating systems and preOS applications difficult. Through the judicious use of GUIDs to name APIs
and an association to develop the specification, UEFI balances the need for API evolution with interoperability
Working with Protocols
Working with Protocols
Any UEFI code can operate with protocols during boot time.
However after ExitBootServices(); is called,, the handle database is no longer available.
Several UEFI boot time services work with UEFI protocols.
Multiple Protocol Instances
A handle may have many protocols attached to it. However, it may have only one protocol of each type. In other words, a handle may not have more than one instance of the exact same protocol. Otherwise, it would make requests for a particular protocol on a handle nondeterministic.
However, drivers may create multiple instances of a particular protocol and attach each instance to a different handle. The PCI I/O Protocol fits this scenario, where the PCI bus driver installs a PCI I/O Protocol instance for each PCI device. Each instance of the PCI I/O Protocol is configured with data values that are unique to that PCI device, including the location and size of the UEFI Option ROM (OpROM) image.
Also, each driver can install customized versions of the same protocol as long as they do not use the same handle. For example, each UEFI driver
installs the Component Name Protocol on its driver image handle, yet when the EFI_COMPONENT_NAME2_PROTOCOL::GetDriverName() function is called, each handle returns the unique name of the driver that
owns that image handle.
The EFI_COMPONENT_NAME2_PROTOCOL::GetDriverName() function on the USB bus driver handle returns "USB bus driver", but on the PXE driver handle it returns "PXE base code driver"