u-boot.git/lib, branch v2025.01

lmb: Return -EEXIST in lmb_add_region_flags() if region already added

2024-12-12T15:20:32+00:00

An attempt to add the already added LMB region using
lmb_add_region_flags() ends up in lmb_addrs_overlap() check, which
eventually leads to either returning 0 if 'flags' is LMB_NONE, or -1
otherwise. It makes it impossible for the user of this function to catch
the case when the region is already added and differentiate it from
regular errors. That in turn may lead to incorrect error handling in the
caller code, like reporting misleading errors or interrupting the normal
code path where it could be treated as the normal case. An example is
boot_fdt_reserve_region() function, which might be called twice (e.g.
during board startup in initr_lmb(), and then during 'booti' command
booting the OS), thus trying to reserve exactly the same memory regions
described in the device tree twice, which produces an error message on
second call.

Return -EEXIST error code in case when the added region exists and it's
not LMB_NONE; for LMB_NONE return 0, to conform to unit tests
(specifically test_alloc_addr() in test/lib/lmb.c) and the preferred
behavior described in commit 1d9aa4a283da ("lmb: Fix the allocation of
overlapping memory areas with !LMB_NONE"). The change of
lmb_add_region_flags() return values is described in the table below:

    Return case                        Pre-1d9   1d9    New
    -----------------------------------------------------------
    Added successfully                    0      0      0
    Failed to add                         -1     -1     -1
    Already added, flags == LMB_NONE      0      0      0
    Already added, flags != LMB_NONE      0      -1     -EEXIST

Rework all affected functions and their documentation. Also fix the
corresponding unit test which checks reserving the same region with the
same flags to account for the changed return value.

No functional change is intended (by this patch itself).

Fixes: 1d9aa4a283da ("lmb: Fix the allocation of overlapping memory areas with !LMB_NONE")
Signed-off-by: Sam Protsenko 
Reviewed-by: Ilias Apalodimas 
Tested-by: Michal Simek

mbedtls: remove MBEDTLS_HAVE_TIME

2024-12-06T23:47:23+00:00

When MbedTLS TLS features were added MBEDTLS_HAVE_TIME was defined as part
of enabling https:// support. However that pointed to the wrong function
which could crash if it received a NULL pointer.

Looking closer that function is not really needed, as it only seems to
increase the RNG entropy by using 4b of the current time and date.
The reason that was enabled is that lwIP was unconditionally requiring it,
although it's configurable and can be turned off.

Since lwIP doesn't use that field anywhere else, make it conditional and
disable it from our config.

Fixes: commit a564f5094f62 ("mbedtls: Enable TLS 1.2 support")
Reported-by: Heinrich Schuchardt 
Signed-off-by: Ilias Apalodimas 
Reviewed-by: Heinrich Schuchardt 
Acked-by: Jerome Forissier

net: disable MBEDTLS in SPL

2024-12-06T23:47:23+00:00

Building SPL fails with MBEDTLS enabled.
Currently we don't need it there.

Signed-off-by: Heinrich Schuchardt 
Acked-by: Jerome Forissier

lmb: prohibit allocations above ram_top even from same bank

2024-12-06T23:47:23+00:00

There are platforms which set the value of ram_top based on certain
restrictions that the platform might have in accessing memory above
ram_top, even when the memory region is in the same DRAM bank. So,
even though the LMB allocator works as expected, when trying to
allocate memory above ram_top, prohibit this by marking all memory
above ram_top as reserved, even if the said memory region is from the
same bank.

Signed-off-by: Sughosh Ganu 
Tested-by: Andreas Schwab

lmb: Fix the allocation of overlapping memory areas with !LMB_NONE

2024-12-05T07:01:44+00:00

At the moment the LMB allocator will return 'success' immediately on two
consecutive allocations if the second one is smaller and the flags match
without resizing the reserved area.

This is problematic for two reasons, first of all the new updated
allocation won't update the size and we end up holding more memory than
needed, but most importantly it breaks the EFI SCT tests since EFI
now allocates via LMB.

More specifically when EFI requests a specific address twice with the
EFI_ALLOCATE_ADDRESS flag set, the first allocation will succeed and
update the EFI memory map. Due to the LMB behavior the second allocation
will also succeed but the address ranges are already in the EFI memory
map due the first allocation. EFI will then fail to update the memory map,
returning EFI_OUT_OF_RESOURCES instead of EFI_NOT_FOUND which break EFI
conformance.

So let's remove the fast check with is problematic anyway and leave LMB
resize and calculate address properly. LMB will now
- try to resize the reservations for LMB_NONE
- return -1 if the memory is not LMB_NONE and already reserved

The LMB code needs some cleanup in that part, but since we are close to
2025.01 do the easy fix and plan to refactor it later.
Also update the dm tests with the new behavior.

Fixes: commit 22f2c9ed9f53 ("efi: memory: use the lmb API's for allocating and freeing memory")
Signed-off-by: Ilias Apalodimas

efi_loader: Check for a valid fw_name before auto generating GUIDs

2024-12-05T07:01:33+00:00

The gen_v5_guid() is a void and does no error checking with pointers
being available etc. Instead it expects all things to be in place to
generate GUIDs. If a board capsule definition is buggy and does not
define the firmware names when enabling capsule updates, the board will
crash trying to bring up the EFI subsystem.

Check for a valid firmware name before generating GUIDs.

Reviewed-by: Heinrich Schuchardt 
Signed-off-by: Ilias Apalodimas

binman: Avoid skipping binman_init()

2024-12-02T13:40:30+00:00

A recent lwip change stopped binman's init from working, so it is not
possible to read nodes from the image description anymore.

Correct this by dropping the offending line.

Signed-off-by: Simon Glass 
Fixes: 4d4d7838127 net: lwip: add TFTP support and tftpboot command

Revert "efi_memory: do not add U-Boot memory to the memory map"

2024-11-30T14:37:53+00:00

This reverts commit ("commit a68c9ac5d8af ("efi_memory: do not add
U-Boot memory to the memory map").

This code was removed when the EFI subsystem started using LMB calls for
the reservations. In hindsight it unearthed two problems.

The e820 code is adding u-boot memory as EfiReservedMemory while it
should look at what LMB added and decide instead of blindly overwriting
it. The reason this worked is that we marked that code properly late,
when the EFI came up. But now with the LMB changes, the EFI map gets
added first and the e820 code overwrites it.

The second problem is that we never mark SetVirtualAddressMap as runtime
code, which we should according to the spec. Until we fix this the
current hack can't go away, at least for architectures that *need* to
call SVAM.

More specifically x86 currently requires SVAM and sets the NX bit for
pages not marked as *_CODE. So unless we do that late, it will crash
trying to execute from non-executable memory. It's also worth noting
that x86 calls SVAM late in the boot, so this will work until someone
decides to overwrite/use BootServicesCode from the OS.

Notably arm64 disables it explicitly if the VA space is > 48bits, so
doesn't suffer from any of these problems.

This doesn't really deserve a fixes tag, since it brings back a hack to
remedy a situation that was wrong long before that commit, but in case
anyone hits the same bug ...
Simon sent the original revert in the link, but we need a proper
justification for it.

Link: https://lore.kernel.org/u-boot/20241112131830.576864-1-sjg@chromium.org/
Signed-off-by: Ilias Apalodimas 
Acked-by: Sughosh Ganu 
Reported-by: Simon Glass

Merge patch series "Fix device removal order for Apple dart iommu"

2024-11-24T21:41:32+00:00

Janne Grunau  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

dm: Add dm_remove_devices_active() for ordered device removal

2024-11-24T21:41:28+00:00

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