| Age | Commit message (Collapse) | Author |
|---|
|
When the LoadImage() UEFI function is called with both its SourceBuffer and
DevicePath input arguments equal to NULL, it must return EFI_NOT_FOUND [1].
However, it does return EFI_INVALID_PARAMETER instead; fix it.
Link: https://uefi.org/specs/UEFI/2.11/07_Services_Boot_Services.html#efi-boot-services-loadimage [1]
Reported-by: Sathisha Shivaramappa <[email protected]>
Signed-off-by: Vincent Stehlé <[email protected]>
Cc: Heinrich Schuchardt <[email protected]>
Cc: Ilias Apalodimas <[email protected]>
Cc: Tom Rini <[email protected]>
|
|
The efi_exit() function frees the loaded image memory by calling
efi_delete_image(). However, when CONFIG_EFI_TCG2_PROTOCOL is enabled, the
image_obj->image_type structure member is accessed after the memory has
been freed.
Fix this by performing the tcg2 measurement before the image deletion.
Fixes: 8fc4e0b4273a ("efi_loader: add boot variable measurement")
Suggested-by: Ilias Apalodimas <[email protected]>
Signed-off-by: Vincent Stehlé <[email protected]>
Cc: Heinrich Schuchardt <[email protected]>
Cc: Tom Rini <[email protected]>
Cc: Masahisa Kojima <[email protected]>
Acked-by: Masahisa Kojima <[email protected]>
Reviewed-by: Heinrich Schuchardt <[email protected]>
|
|
This commit adds the functionality of generate EFI_DEBUG_IMAGE_INFO
while loading the image.
This feature is described in UEFI Spec 2.10. Section 18.4.3.
The implementation ensures support for hardware-assisted debugging and
provides a standardized mechanism for debuggers to discover the load
address of an EFI application.
Cc: Ilias Apalodimas <[email protected]>
Cc: Peter Robinson <[email protected]>
Cc: Simon Glass <[email protected]>
Signed-off-by: Ying-Chun Liu (PaulLiu) <[email protected]>
Tested-by: Heinrich Schuchardt <[email protected]>
Acked-by: Ilias Apalodimas <[email protected]>
Signed-off-by: Ilias Apalodimas <[email protected]>
|
|
The global gd pointer is no longer volatile-qualified, so drop that
qualifier from these bookkeeping variables.
Signed-off-by: Rasmus Villemoes <[email protected]>
Reviewed-by: Heinrich Schuchardt <[email protected]>
|
|
These functions are useful for the EFI app. As a first step towards
making these available outside lib/efi_loader, create a separate header
file and include it where needed. Add proper comments to the functions,
since many are missing at present.
Signed-off-by: Simon Glass <[email protected]>
Reviewed-by: Heinrich Schuchardt <[email protected]>
|
|
When starting image add the image load address to the debug output.
Signed-off-by: Heinrich Schuchardt <[email protected]>
Reviewed-by: Ilias Apalodimas <[email protected]>
|
|
Note that this undoes the changes of commit cf6d4535cc4c ("x86:
emulation: Disable bloblist for now") as that was intended only for the
release due to time.
|
|
It has been reported that memory corruption can occurred because network
packages where received after EXIT_BOOT_SERVICES. See the thread
starting at [1].
We try to remove all drivers when EXIT_BOOT_SERVICES is called. But
* Some network drivers don't call their own stop method when removed.
* Some network drivers don't have a remove method.
* Some devices have CONFIG_DM_DEVICE_REMOVE=n.
Let's call eth_halt() in EXIT_BOOT_SERVICES explicitly.
[1]
https://lore.kernel.org/all/[email protected]/
Cc: Michael Brown <[email protected]>
Reported-by: Christian Kohlschütter <[email protected]>
Signed-off-by: Heinrich Schuchardt <[email protected]>
Reviewed-by: Michael Brown <[email protected]>
Reviewed-by: Ilias Apalodimas <[email protected]>
Tested-by: Christian Kohlschütter <[email protected]>
|
|
https://source.denx.de/u-boot/custodians/u-boot-dfu into next
u-boot-dfu-next-20250310
CI:
- https://source.denx.de/u-boot/custodians/u-boot-dfu/-/pipelines/25060
Usb gadget:
- Remove legacy CONFIG_USB_DEVICE
- Remove legacy usbtty driver
|
|
The lone user of the legacy USB device framework have been removed for
some time. Remove the final parts of the code that were missed.
Signed-off-by: Tom Rini <[email protected]>
Reviewed-by: Mattijs Korpershoek <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Mattijs Korpershoek <[email protected]>
|
|
Structure jmp_buf_data provides the underlying format of jmp_buf, which
we actually don't care about. Clean up existing code to use the standard
jmp_buf type. This introduces no functional change.
Signed-off-by: Yao Zi <[email protected]>
Reviewed-by: Jerome Forissier <[email protected]>
Reviewed-by: Ilias Apalodimas <[email protected]>
|
|
Separate setjmp.h into an architecture independent part and an architecture
specific part. This simplifies moving from using struct jmp_buf_data
directly to using type jmp_buf in our code which is the C compliant way.
Reviewed-by: Jerome Forissier <[email protected]>
Signed-off-by: Heinrich Schuchardt <[email protected]>
|
|
The following symbols are exposed:
- efi_reinstall_protocol_interface
This is done so that the device path protocol interface
of the network device can be changed internally by u-boot
when a new bootfile gets downloaded.
- eth_set_dev
To support multiple network udevices
- efi_close_event
This comes in preparation to support unregistering
an EFI network device from the EFI network stack when
the underlying U-boot device gets removed
- efi_[dis]connect_controller
The EFI network driver uses ConnectController to add a
NIC to the EFI network stack.
- efi_uninstall_protocol_interface
connect_controler for the efi network driver can install
protocols, which need to be uninstalled in disconnect_controller
- EFI_SIMPLE_NETWORK_PROTOCOL_GUID
Signed-off-by: Adriano Cordova <[email protected]>
|
|
The log category should be LOGC_EFI all over the EFI sub-system.
Signed-off-by: Heinrich Schuchardt <[email protected]>
Reviewed-by: Ilias Apalodimas <[email protected]>
|
|
When logging running an image, e.g. `bootefi hello` the indent is not
correctly reset.
Signed-off-by: Heinrich Schuchardt <[email protected]>
|
|
This is done so that the device path protocol interface of the network
device can be changed internally by u-boot when a new bootfile gets
downloaded.
Signed-off-by: Adriano Cordova <[email protected]>
Reviewed-by: Heinrich Schuchardt <[email protected]>
Reviewed-by: Ilias Apalodimas <[email protected]>
|
|
We should not write messages in UEFI API functions. This may lead to
incorrect screen layout in UEFI application.
For single statements after if clause we don't need braces.
Reviewed-by: Ilias Apalodimas <[email protected]>
Signed-off-by: Heinrich Schuchardt <[email protected]>
|
|
This replaces dm_remove_devices_flags() calls in all boot
implementations to ensure non vital devices are consistently removed
first. All boot implementation except arch/arm/lib/bootm.c currently
just call dm_remove_devices_flags(DM_REMOVE_ACTIVE_ALL). This can result
in crashes when dependencies between devices exists. The driver model's
design document describes DM_FLAG_VITAL as "indicates that the device is
'vital' to the operation of other devices". Device removal at boot
should follow this.
Instead of adding dm_remove_devices_flags() with (DM_REMOVE_ACTIVE_ALL |
DM_REMOVE_NON_VITAL) everywhere add dm_remove_devices_active() which
does this.
Fixes a NULL pointer deref in the apple dart IOMMU driver during EFI
boot. The xhci-pci (driver which depends on the IOMMU to work) removes
its mapping on removal. This explodes when the IOMMU device was removed
first.
dm_remove_devices_flags() is kept since it is used for testing of
device_remove() calls in dm.
Signed-off-by: Janne Grunau <[email protected]>
|
|
Simplify the code by using the list_count_nodes() function.
Signed-off-by: Heinrich Schuchardt <[email protected]>
|
|
We can reuse this function to load the device-tree.
Signed-off-by: Heinrich Schuchardt <[email protected]>
Reviewed-by: Ilias Apalodimas <[email protected]>
|
|
Allow appending a device-path to a device-path that contains an end node
as separator. We need this feature for creating boot options specifying
kernel, initrd, and dtb.
Signed-off-by: Heinrich Schuchardt <[email protected]>
Reviewed-by: Ilias Apalodimas <[email protected]>
|
|
Looking back at the initrd storing functionality, we introduced three
functions, efi_dp_append_or_concatenate(), efi_dp_append/concat(). In
hindsight we could have simplified that by a lot. First of all none of
the functions append anything. They all allocate a new device path and
concatenate the contents of two device paths in one. A boolean parameter
controls the final device path -- if that's true an end node is injected
between the two device paths.
So let's rewrite this and make it a bit easier to read. Get rid of
efi_dp_append(), efi_dp_concat() and rename
efi_dp_append_or_concatenate() to efi_dp_concat(). This is far more
intuitive and the only adjustment that is needed is an extra boolean
argument on all callsites.
Signed-off-by: Ilias Apalodimas <[email protected]>
|
|
We largely do not need <common.h> in these files, so drop it. The only
exception here is that efi_freestanding.c needs <linux/types.h> and had
been getting that via <common.h>.
Reviewed-by: Simon Glass <[email protected]>
Signed-off-by: Tom Rini <[email protected]>
|
|
Prepare v2024.01-rc5
|
|
commit 239d59a65e20 ("efi_loader: reconnect drivers on failure")
tried to fix the UninstallProtocol interface which must reconnect
any controllers it disconnected by calling ConnectController()
in case of failure. However, the reconnect functionality was wired in
efi_disconnect_all_drivers() instead of efi_uninstall_protocol().
As a result some SCT tests started failing.
Specifically, BBTestOpenProtocolInterfaceTest333CheckPoint3() test
- Calls ConnectController for DriverImageHandle1
- Calls DisconnectController for DriverImageHandle1 which will
disconnect everything apart from TestProtocol4. That will remain
open on purpose.
- Calls ConnectController for DriverImageHandle2. TestProtocol4
which was explicitly preserved was installed wth BY_DRIVER attributes.
The new protocol will call DisconnectController since its attributes
are BY_DRIVER|EXCLUSIVE, but TestProtocol4 will not be removed. The
test expects EFI_ACCESS_DENIED which works fine.
The problem is that DisconnectController, will eventually call
EFI_DRIVER_BINDING_PROTOCOL.Stop(). But on the aforementioned test
this will call CloseProtocol -- the binding protocol is defined in
'DBindingDriver3.c' and the .Stop function uses CloseProtocol.
If that close protocol call fails with EFI_NOT_FOUND, the current code
will try to mistakenly reconnect all drivers and the subsequent tests
that rely on the device being disconnected will fail.
Move the reconnection in efi_uninstall_protocol() were it belongs.
Fixes: commit 239d59a65e20 ("efi_loader: reconnect drivers on failure")
Signed-off-by: Ilias Apalodimas <[email protected]>
Reviewed-by: Heinrich Schuchardt <[email protected]>
|
|
When the image loaded by efibootmgr returns, efibootmgr
needs to clean the resources. Adding the event of returning
to efibootmgr is useful to simplify the implementation.
Signed-off-by: Masahisa Kojima <[email protected]>
Reviewed-by: Ilias Apalodimas <[email protected]>
Signed-off-by: Ilias Apalodimas <[email protected]>
|
|
const classifier is missing in EventGroup parameter of
CreateEventEx(). Fix it to remove the compiler warning.
NotifyContext parameter of CreateEventEx() is also defined
with const in UEFI specification, but NotifyContext parameter
of CreateEvent() is defined without const.
Since current implementation calls the common efi_create_event()
function from both CreateEventEx() and CreateEvent() services,
NotifyContext parameter leaves as is.
Signed-off-by: Masahisa Kojima <[email protected]>
Reviewed-by: Ilias Apalodimas <[email protected]>
Signed-off-by: Ilias Apalodimas <[email protected]>
|
|
When a notification event is registered for a protocol the handle of the
protocol is added in our event notification list. When all the protocols
of the handle are uninstalled we delete the handle but we do not remove
it from the event notification list.
Clean up the protocol removal functions and add a wrapper which
- Removes the to-be deleted handle from any lists it participates
- Remove the handle if no more protocols are present
Signed-off-by: Ilias Apalodimas <[email protected]>
Reviewed-by: Heinrich Schuchardt <[email protected]>
|
|
The EFI doesn't allow removal of handles, unless all hosted protocols
are cleanly removed. Our efi_delete_handle() is a bit intrusive.
Although it does try to delete protocols before removing a handle,
it doesn't care if that fails. Instead it only returns an error if the
handle is invalid. On top of that none of the callers of that function
check the return code.
So let's rewrite this in a way that fits the EFI spec better. Instead
of forcing the handle removal, gracefully uninstall all the handle
protocols. According to the EFI spec when the last protocol is removed
the handle will be deleted. Also switch all the callers and check the
return code. Some callers can't do anything useful apart from reporting
an error. The disk related functions on the other hand, can prevent a
medium that is being used by EFI from removal.
The only function that doesn't check the result is efi_delete_image().
But that function needs a bigger rework anyway, so we can clean it up in
the future
Signed-off-by: Ilias Apalodimas <[email protected]>
Reviewed-by: Heinrich Schuchardt <[email protected]>
|
|
A previous patch is removing the last consumer of efi_remove_protocol().
Switch that to static and treat it as an internal API in order to force
users install and remove protocols with the appropriate EFI functions.
It's worth noting that we still have files using efi_add_protocol(). We
should convert all these to efi_install_multiple_protocol_interfaces()
and treat efi_add_protocol() in a similar manner
Reviewed-by: Heinrich Schuchardt <[email protected]>
Signed-off-by: Ilias Apalodimas <[email protected]>
|
|
The call to efi_search_obj() is redundant as the function is called in
efi_search_protocol() too.
Signed-off-by: Heinrich Schuchardt <[email protected]>
Reviewed-by: Ilias Apalodimas <[email protected]>
|
|
Up to now we did not check the return value of DisconnectController.
A previous patch is fixing that taking into account what happened during
the controller disconnect. But that check takes place before our code
is trying to figure out if the interface exists to begin with. In case a
driver is not allowed to unbind -- e.g returning EFI_DEVICE_ERROR, we
will end up returning that error instead of EFI_NOT_FOUND.
Add an extra check on the top of the function to make sure the protocol
interface exists before trying to disconnect any drivers
Reviewed-by: Heinrich Schuchardt <[email protected]>
Signed-off-by: Ilias Apalodimas <[email protected]>
|
|
efi_uninstall_protocol() calls efi_disconnect_all_drivers() but never
checks the return value. Instead it tries to identify protocols that
are still open after closing the ones that were opened with
EFI_OPEN_PROTOCOL_BY_HANDLE_PROTOCOL, EFI_OPEN_PROTOCOL_GET_PROTOCOL
and EFI_OPEN_PROTOCOL_TEST_PROTOCOL.
Instead of doing that, check the return value early and exit if
disconnecting the drivers failed. Also reconnect all the drivers of
a handle if protocols are still found on the handle after disconnecting
controllers and closing the remaining protocols.
While at it fix a memory leak and properly free the opened protocol
information when closing a protocol.
Signed-off-by: Ilias Apalodimas <[email protected]>
Reviewed-by: Heinrich Schuchardt <[email protected]>
|
|
efi_disconnect_controller() doesn't reconnect drivers in case of
failure. Reconnect the disconnected drivers properly
Signed-off-by: Ilias Apalodimas <[email protected]>
Reviewed-by: Heinrich Schuchardt <[email protected]>
|
|
efi_event_queue and efi_register_notify_events are only referenced
in efi_boottime.c
Signed-off-by: Bin Meng <[email protected]>
|
|
Make functions that are no used externally static.
Signed-off-by: Heinrich Schuchardt <[email protected]>
|
|
HandleProtocol() is deprecrated. According to the UEFI specification it
should be implemented as a call to OpenProtocolInterface() with a hard
coded agent handle. This implies that we would have to call
CloseProtocolInterfaces() after usage with the same handle.
Getting rid of an EFI_CALL() is also appreciated.
Signed-off-by: Heinrich Schuchardt <[email protected]>
Acked-by: Ilias Apalodimas <[email protected]>
|
|
The fields ConsoleInHandle, ConsoleOutHandle, ConsoleErrHandle must point
to the handles with the respective console protocols. Failure to do so
leads to an error in the EFI Shell:
No SimpleTextInputEx was found. CTRL-based features are not usable.
Signed-off-by: Heinrich Schuchardt <[email protected]>
Reviewed-by: Ilias Apalodimas <[email protected]>
|
|
efi_uninstall_multiple_protocol_interfaces_int()
If the va_list we got handed over contains no protocols we must return
EFI_SUCCESS. However in that case the current code just returns
an unintialized value.
Fix that by setting the return value in the variable definition
Addresses-Coverity: CID 376195: ("Uninitialized variables (UNINIT)")
Signed-off-by: Ilias Apalodimas <[email protected]>
Reviewed-by: Heinrich Schuchardt <[email protected]>
|
|
Allow avoiding using EFI_CALL() when closing a protocol by providing an
internal function.
Signed-off-by: Heinrich Schuchardt <[email protected]>
Reviewed-by: Ilias Apalodimas <[email protected]>
|
|
A following patch is cleaning up the core EFI code trying to remove
sequences of efi_create_handle, efi_add_protocol.
Although this works fine there's a problem with the latter since it is
usually combined with efi_delete_handle() which blindly removes all
protocols on a handle and deletes the handle. We should try to adhere to
the EFI spec which only deletes a handle if the last instance of a protocol
has been removed. Another problem is that efi_delete_handle() never checks
for opened protocols, but the EFI spec defines that the caller is
responsible for ensuring that there are no references to a protocol
interface that is going to be removed.
So let's fix this by replacing all callsites of
efi_create_handle(), efi_add_protocol() , efi_delete_handle() with
Install/UninstallMultipleProtocol.
In order to do that redefine functions that can be used by the U-Boot
proper internally and add '_ext' variants that will be used from the
EFI API
Signed-off-by: Ilias Apalodimas <[email protected]>
Reviewed-by: Heinrich Schuchardt <[email protected]>
|
|
Signed-off-by: Tom Rini <[email protected]>
|
|
Globally replace all occurances of WATCHDOG_RESET() with schedule(),
which handles the HW_WATCHDOG functionality and the cyclic
infrastructure.
Signed-off-by: Stefan Roese <[email protected]>
Reviewed-by: Simon Glass <[email protected]>
Tested-by: Tom Rini <[email protected]> [am335x_evm, mx6cuboxi, rpi_3,dra7xx_evm, pine64_plus, am65x_evm, j721e_evm]
|
|
This commit add the "eficonfig" command.
The "eficonfig" command implements the menu-driven UEFI boot option
maintenance feature. This commit implements the addition of
new boot option. User can select the block device volume having
efi_simple_file_system_protocol and select the file corresponding
to the Boot#### variable. User can also enter the description and
optional_data of the BOOT#### variable in utf8.
This commit adds "include/efi_config.h", it contains the common
definition to be used from other menus such as UEFI Secure Boot
key management.
Signed-off-by: Masahisa Kojima <[email protected]>
|
|
Change efi_delete_handle() to not free EFI handles twice.
This change tries to resolved an issue seen since U-Boot v2022.07
in which ExitBootService() attempts to release some EFI handles twice.
The issue was seen booting a EFI shell that invokes 'connect -r' and
then boots a Linux kernel. Execution of connect command makes EFI
subsystem to bind a block device for each root block devices EFI handles.
However these EFI device handles are already bound to a driver and we
can have 2 registered devices relating to the same EFI handler. On
ExitBootService(), the loop removing the devices makes these EFI handles
to be released twice which corrupts memory.
This patch prevents the memory release operation caused by the issue but
but does not resolve the underlying problem.
Signed-off-by: Etienne Carriere <[email protected]>
Add log message.
Reviewed-by: Heinrich Schuchardt <[email protected]>
Reviewed-by: Ilias Apalodimas <[email protected]>
|
|
This function will be used in the next commit where some behavior
of EFI boot manager will be expanded.
Signed-off-by: AKASHI Takahiro <[email protected]>
Reviewed-by: Ilias Apalodimas <[email protected]>
Reviewed-by: Heinrich Schuchardt <[email protected]>
|
|
The boot manager must support loading from boot options using a short-form
device-path, e.g. one where the first element is a hard drive media path.
See '3.1.2 Load Options Processing' in UEFI specification version 2.9.
Fixes: 0e074d12393b ("efi_loader: carve out efi_load_image_from_file()")
Signed-off-by: Heinrich Schuchardt <[email protected]>
|
|
Let function efi_dp_find_obj() additionally check if a given protocol is
installed on the handle relating to the device-path.
Signed-off-by: Heinrich Schuchardt <[email protected]>
|
|
InstallProtocolInterface() is called with a pointer to the protocol GUID.
There is not guarantee that the memory used by the caller for the protocol
GUID stays allocated. To play it safe the GUID should be copied to U-Boot's
internal structures.
Reported-by: Joerie de Gram <[email protected]>
Signed-off-by: Heinrich Schuchardt <[email protected]>
|
|
efi_uintnt_t is an unsigned type. We should avoid showing negative numbers.
Signed-off-by: Heinrich Schuchardt <[email protected]>
|
