Janne Grunau <j@jannau.net> says:
Starting with v2024.10 dev_iommu_dma_unmap calls during device removal
trigger a NULL pointer dereference in the Apple dart iommu driver. The
iommu device is removed before its user. The sparsely used DM_FLAG_VITAL
flag is intended to describe this dependency. Add it to the driver.
Adding this flag is unfortunately not enough since the boot routines
except the arm one simply remove all drivers. Add and use a new function
which calls
dm_remove_devioce_flags(DM_REMOVE_ACTIVE_ALL | DM_REMOVE_NON_VITAL);
dm_remove_devices_flags(DM_REMOVE_ACTIVE_ALL);
to ensure this order dependency is head consistently.
Link: https://lore.kernel.org/r/20241123-iommu_apple_dart_ordering-v2-0-cc2ade6dde97@jannau.net
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 <j@jannau.net>
We never free and unmap the memory on errors and we never unmap it when
freeing it. The latter won't cause any problems even on sandbox, but for
consistency always use unmap_sysmem()
Fixes: commit 22f2c9ed9f53 ("efi: memory: use the lmb API's for allocating and freeing memory")
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Commit 775f7657ba58 ("Kconfig: clean up the efi configuration status")
by mistake revoked commit dcd1b63b7072 ("efi_loader: allow
EFI_LOADER_BOUNCE_BUFFER on all architectures").
Fixes: 775f7657ba58 ("Kconfig: clean up the efi configuration status")
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Tested-by: Loic Devulder <ldevulder@suse.com>
The value of variable nt is never used. Just use NULL when calling efi_check_pe(). The API function is not expected to write to the console. Such output might have unwanted side effects on the screen layout of an EFI application. Leave error handling to the caller. Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com> Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Rather than returning 0, just return an error, since sandbox is not used with PXE at present. Signed-off-by: Simon Glass <sjg@chromium.org>
When the --native flag is given, pretend to be running the host architecture rather than sandbox. Allow the same control for PXE too. Signed-off-by: Simon Glass <sjg@chromium.org>
Move this function from the EFI bootmeth to the common efi_helper file. No functional change is intended. Signed-off-by: Simon Glass <sjg@chromium.org>
Use a function to obtain the device EFI filename, so that we can control how sandbox behaves. Signed-off-by: Simon Glass <sjg@chromium.org>
Add a simple app to use for testing. This is intended to do whatever it needs to for testing purposes. For now it just prints a message and exits boot services. There was a considerable amount of discussion about whether it is OK to call exit-boot-services and then return to U-Boot. This is not normally done in a real application, since exit-boot-services is used to completely disconnect from U-Boot. For now, this part is skipped. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>