| Age | Commit message (Collapse) | Author |
|---|
|
Pull request net-20260623.
net:
- airoha_eth: fix mt7531 mdio related initialization bug
net-legacy:
- cdp: reject CDP TLVs with a length below the 4-byte header
- Clear IP defragmentation state after returning a complete packet
net-lwip:
- Halt ethernet after network commands
|
|
cdp_receive() reads a 16-bit TLV length (tlen) from the packet and only
checks that it does not exceed the remaining buffer (tlen > len). It then
unconditionally does "tlen -= 4" to skip the TLV header. As tlen is a
u16, a crafted TLV with a length of 0..3 underflows tlen to ~65532-65535.
For a CDP_APPLIANCE_VLAN_TLV the underflowed length then drives the inner
"while (tlen > 0)" loop, which walks ~64KB past the receive buffer reading
*ss each step -> out-of-bounds read (crash / info-influence). A length of
0 additionally fails to advance pkt/len, hanging the parse loop.
Reject any TLV whose declared length is smaller than its own 4-byte
header. This is the same class of bug as the recent bootp/dhcpv6/sntp/nfs
fixes (unchecked length field), in a sibling LAN parser that was missed.
Verified with a standalone AddressSanitizer harness using the verbatim
cdp_receive()/cdp_compute_csum() routines: a 16-byte CDP frame with an
appliance-VLAN TLV of length 3 triggers a heap-buffer-overflow READ that
the check eliminates.
Fixes: f575ae1f7d39 ("net: Move CDP out of net.c")
Cc: [email protected]
Signed-off-by: Piyush Paliwal <[email protected]>
Reviewed-by: Jerome Forissier <[email protected]>
|
|
Add a introduce net_lwip_eth_stop() function and use that to stop the
network interface after each command that uses the network.
This makes the behavior the same as the legacy net code and avoids
potential issues with the network interface being left in an active
state after a command finishes.
The start/stop is reference-counted since there is at least one command
(dhcp) that calls another command (tftp) to avoid starting and stopping
the network interface multiple times in a single command.
Signed-off-by: David Lechner <[email protected]>
Reviewed-by: Jerome Forissier <[email protected]>
|
|
Change the return values of the lwip implementation of wget_do_request()
to be errno codes instead of command return codes.
wget_do_request() is not a command, so it does not make sense to return
command return codes from it. Also, the legacy network implementation of
wget_do_request() already returns errno codes so it is logical for the
lwip implementation to do the same.
This fixes a bug in try_load_from_uri_path() in efi_manager.c where it
checks that the return value of wget_do_request() is < 0. Before this
change, CMD_RET_FAILURE would not be considered an error since it has a
value of 1.
The value of ENODEV is used in places where there could actually be a
number of different causes of failure and it isn't possible to
discriminate (i.e. failing function returns NULL for all errors). Since
all callers of wget_do_request() don't propagate the error code, it
doesn't matter so much that this is not ideal, at least at this point in
time.
Fixes: 3c656c928bd7 ("net: lwip: add wget command")
Reviewed-by: Jerome Forissier <[email protected]>
Signed-off-by: David Lechner <[email protected]>
|
|
Split wget_do_request() into two functions to make error handling less
error-prone.
After a successful call to net_lwip_new_netif(), net_lwip_remove_netif()
must always be called to prevent leaks. This was missed in the CACERT
section of the code where we returned on error without cleaning up.
Instead of adding more calls to net_lwip_remove_netif(), refactor the
code into two functions. The outer function handles managing the netif
lifecycle. The inner function no longer has to worry about cleaning up
before returning on error.
To keep things simple, the `path` local variable is removed during the
refactoring. Instead, ctx.path is used directly everywhere.
Fixes: 3c656c928bd7 ("net: lwip: add wget command")
Reviewed-by: Jerome Forissier <[email protected]>
Acked-by: Ilias Apalodimas <[email protected]>
Signed-off-by: David Lechner <[email protected]>
|
|
Add a unit test for the IP datagram reassembler (CONFIG_IP_DEFRAG) that
covers the duplicate-last-fragment scenario.
Without the fix the last fragment will re-trigger datagram delivery,
increasing udp_rx_count to 2 and effectively failing the test; with it
applied the test passes with udp_rx_count == 1.
Signed-off-by: Mateusz Furdyna <[email protected]>
Reviewed-by: Simon Glass <[email protected]>
|
|
During the IP defragmentation process, after the reassembly is finished
with the last packet arriving with MF=0, the reassembly state wrt.
static counters is not cleared. In case this last arriving packet with
MF=0 gets duplicated, payload bytes are mistakenly treated as hole data.
A malicious actor who can deliver fragmented IP traffic to a U-Boot
instance with CONFIG_IP_DEFRAG=y can corrupt memory via out-of-bound
writes and redirect control flow into attacker-supplied payload bytes
that already sit in `pkt_buff[]`.
Publicly available AI models are able to generate a reproducer based
on the provided information.
Fix: once the assembled packet has been handed back to the caller, mark
the reassembly state empty so that any further fragment (duplicate,
replay, or a brand-new datagram that happens to reuse the `ip_id`) goes
through the normal re-init path and rebuilds a clean hole list instead
of dereferencing payload bytes as struct hole.
Fixes: 5cfaa4e54d0e ("net: defragment IP packets")
Reported-by: Mariusz Madej <[email protected]>
Reviewed-by: Simon Glass <[email protected]>
Acked-by: Alessandro Rubini <[email protected]>
Signed-off-by: Mateusz Furdyna <[email protected]>
|
|
Private data isn't ready during bind time. The call of dev_get_priv()
function will return NULL. Thus we can't save mdio device pointer and
use it later during probe.
To solve an issue, we will move mt7531 mdio device binding to the probing
function of 'airoha-eth' driver.
All GDM ports (except of GDM1) are connected directly to their PHYs, so
corresponding mdio bus will be automatically probed during PHY setup.
GDM1 ports differ from other GDM ports. It connected to the airoha switch
device. The mt7531 mdio bus is used to manage link state of airoha switch
device ports (LAN ports 1-4 corresponds to PHYs 0x09-0x0C). Therefore,
manual probing of mt7531 mdio bus is required to be able set/query states
of corresponding LAN ports.
Fixes: 96d9e7c46425 ("net: airoha: use mt7531 mdio for GDM1")
Signed-off-by: Mikhail Kshevetskiy <[email protected]>
|
|
Prepare v2026.07-rc5
|
|
Signed-off-by: Tom Rini <[email protected]>
|
|
- serial: sh: Fix dev_read_addr error check
|
|
dev_read_addr returns FDT_ADDR_T_NONE (-1) in case of error
and not 0.
Signed-off-by: Francois Berder <[email protected]>
Reviewed-by: Simon Glass <[email protected]>
Reviewed-by: Marek Vasut <[email protected]>
Tested-by: Marek Vasut <[email protected]> # R-Car H3/M3-W/M3-N Salvator-X(S), H3/M3-W ULCB, V4H Sparrow Hawk, X5H Ironhide RSIP and CA720AE
Signed-off-by: Marek Vasut <[email protected]> # Update subject tags
|
|
https://source.denx.de/u-boot/custodians/u-boot-efi
Pull request efi-2026-07-rc6
CI: https://source.denx.de/u-boot/custodians/u-boot-efi/-/pipelines/30505
Documentation:
* bootdev: fix typos
* board: renesas: Document Renesas RZ/N1D and RZ/N1S as arm
* board: renesas: Document Renesas Geist board support
* board: renesas: Document Renesas Gray Hawk board support
* board: renesas: Document Renesas Ironhide board support
* android: fastboot: Document halt behaviour
UEFI:
* fix memory leak in efi_var_collect()
* set revision field in block IO protocol
* fix guid comparison in efi_selftest_loaded_image.c
* fix use-after-free in efi_selftest_memory.c
|
|
It's possible to interrupt the fastboot command from the U-Boot shell
using the Ctrl-c keybinding.
Document this.
Signed-off-by: Mattijs Korpershoek <[email protected]>
Reviewed-by: Sam Day <[email protected]>
|
|
When the `memory' efi selftest verifies the Devicetree memory reservation,
it accesses the memory_map buffer after it has been freed with free_pool().
Move the verification earlier to fix this.
Fixes: 34c96659ed57 ("efi_selftest: check fdt is marked as runtime data")
Signed-off-by: Vincent Stehlé <[email protected]>
Cc: Heinrich Schuchardt <[email protected]>
Cc: Ilias Apalodimas <[email protected]>
Cc: Tom Rini <[email protected]>
Reviewed-by: Ilias Apalodimas <[email protected]>
Reviewed-by: Heinrich Schuchardt <[email protected]>
|
|
The Revision field of the EFI_BLOCK_IO_PROTOCOL structure must be set to
one of the two valid values [1], but this is not initialized in the
efi_loader; fix it.
Link: https://uefi.org/specs/UEFI/2.11/13_Protocols_Media_Access.html#efi-block-io-protocol [1]
Signed-off-by: Vincent Stehlé <[email protected]>
Cc: Heinrich Schuchardt <[email protected]>
Cc: Ilias Apalodimas <[email protected]>
Cc: Tom Rini <[email protected]>
Reviewed-by: Heinrich Schuchardt <[email protected]>
|
|
Barebox has now ported some of the UEFI code. In the process
they found some bugs.
In this case when the variable buffer is too small, efi_var_collect()
returns EFI_BUFFER_TOO_SMALL but doesn't free the allocated 'buf'.
Fixes: 5f7dcf079de8c ("efi_loader: UEFI variable persistence")
Signed-off-by: Ilias Apalodimas <[email protected]>
Reviewed-by: Heinrich Schuchardt <[email protected]>
|
|
Signed-off-by: Denis Mukhin <[email protected]>
Reviewed-by: Heinrich Schuchardt <[email protected]>
Reviewed-by: Simon Glass <[email protected]>
|
|
The `loaded image' efi selftest is comparing protocol GUIDs with the wrong
polarity.
This can be verified on the sandbox, where two protocols GUIDs are
retrieved by the test from the image handle in the following order:
1. Loaded Image Device Path Protocol GUID
2. Loaded Image Protocol GUID
The test matches on the first GUID, while it is in fact looking for the
second one; fix the comparison polarity.
Fixes: efe79a7c0de0 ("efi_selftest: test for loaded image protocol")
Signed-off-by: Vincent Stehlé <[email protected]>
Cc: Heinrich Schuchardt <[email protected]>
Cc: Ilias Apalodimas <[email protected]>
Cc: Tom Rini <[email protected]>
Cc: Alexander Graf <[email protected]>
Reviewed-by: Heinrich Schuchardt <[email protected]>
|
|
Document support for Renesas Ironhide development board
based on Renesas R-Car X5H (R8A78000) SoC.
Fixes: cf71963778ee ("arm64: dts: renesas: Add Renesas R-Car X5H R8A78000 Ironhide board code")
Fixes: 9d47a5a4d560 ("arm: renesas: Add Renesas R-Car R8A78000 X5H Cortex-M33 RSIP port")
Signed-off-by: Marek Vasut <[email protected]>
|
|
Document support for Renesas Gray Hawk Single development board
based on Renesas R-Car V4M (R8A779H0) SoC.
Fixes: 53066deccbed ("ARM: renesas: Add Renesas R8A779H0 V4M Gray Hawk board code")
Signed-off-by: Marek Vasut <[email protected]>
|
|
Document support for Renesas Geist development board
based on Renesas R-Car M3Le (R8A779MD) SoC.
Fixes: c8523795d796 ("arm64: dts: renesas: r8a779md: Add support for R-Car M3Le R8A779MD Geist")
Signed-off-by: Marek Vasut <[email protected]>
|
|
The RZ/N1D and RZ/N1S contain Cortex-A7 core, which is 32bit ARM core.
Document the SoC as 32bit ARM instead of aarch64.
Fixes: a5b9f959439b ("doc: renesas: add Renesas board docs")
Signed-off-by: Marek Vasut <[email protected]>
Reviewed-by: Heinrich Schuchardt <[email protected]>
|
|
- usb: tcpm: fix inverted poll condition in tcpm_pd_transmit()
|
|
The read_poll_timeout() macro breaks out of its loop when the condition
evaluates to true. The current code uses "!tx_complete" as the
condition, which means it exits immediately when tx_complete is false
(i.e., transmission has NOT completed yet), rather than waiting for
completion.
Fix the condition to "tx_complete" so that the poll loop waits until
the TCPC signals transmission success/failure/discard before
proceeding.
Without this fix, tcpm_pd_transmit() returns before the TCPC has
finished transmitting, causing the PD state machine to proceed with
stale tx_status values.
Fixes: 1db4c0ac77e3 ("usb: tcpm: add core framework")
Reviewed-by: Neil Armstrong <[email protected]>
Signed-off-by: Peng Fan <[email protected]>
|
|
Francesco Valla <[email protected]> says:
This patch set contains a collection of small fixes and cleanups for the
"full" FIT loader that can be used for the SPL. The main beneficiary is
the falcon boot flow, but the same loader can be used also for U-Boot
proper.
Patch 1 was part of another set, but I decided to put it here for a
better separation between plumbing (here) and new features (there). I
kept the Reviewed-by tag collected from Simon in that occasion.
Patch 6 introduces a new unit test covering most of the code that is
being cleaned up.
The set was tested on a i.MX93 FRDM, both with and without signature and
to boot both U-Boot proper and the Linux kernel directly (i.e., falcon
boot).
Link: https://lore.kernel.org/r/[email protected]
|
|
Following what is already done for the "simple" FIT loader, add a unit
test for the "full" loader.
Signed-off-by: Francesco Valla <[email protected]>
|
|
Replace #ifdef directives with the CONFIG_IS_ENABLED() for better
coverage and cleaner code. In the mean time, convert the last
IS_ENABLED() to CONFIG_IS_ENABLED().
Signed-off-by: Francesco Valla <[email protected]>
|
|
The 'standalone =' config property has been deprecated for ~5 years [1],
with the loud warn about the deprecation lasting much more than the
foreseen couple of releases.
Remove the attempt to load the primary image through this property to
save some boot time and code complexity.
[1] https://lore.kernel.org/u-boot/[email protected]/
Signed-off-by: Francesco Valla <[email protected]>
|
|
U-Boot proper expects its FDT to be right after its binary image; the
"full" FIT image loader thus adopts an hack to relocate it, ignoring
the specified load address.
Rework the current form of the hack to:
- support the 'sandbox' environment with a sysmem-aware memcpy;
- use the ALIGN() macro instead of raw alignment logic;
- align the FDT to 8-byte boundary as per FDT specifications;
- fix the debug print (which was reporting the source address for the
relocation instead of the destination one).
Signed-off-by: Francesco Valla <[email protected]>
|
|
Align the fit_image_load() call done for the loadables to the ones for
other artifatcs (firmware, kernel, fdt), calling virt_to_phys() on the
pointer that contains the FIT location.
This is needed to support the 'sandbox' environment.
Signed-off-by: Francesco Valla <[email protected]>
|
|
Align the behavior of fit_image_verify() called in SPL to the one in
full U-Boot. In particular, this function is called when both
CONFIG_SPL_LOAD_FIT_FULL and CONFIG_SPL_FIT_SIGNATURE are set (which can
happen e.g. in case of secure falcon boot).
Reviewed-by: Simon Glass <[email protected]>
Signed-off-by: Francesco Valla <[email protected]>
|
|
Tom Rini <[email protected]> says:
As part of the resync to dtc version v1.7.2-35-g52f07dcca47c from the
Linux Kernel, we missed updating the fdt_check_full function because it
exists in its own file in upstream dtc and the kernel doesn't import it,
as reported by Anton Ivanov. This short series brings in the upstream
fdt_check.c file and then implements our size-saving option, but in the
modern way.
The size-saving portion has been upstreamed.
Link: https://lore.kernel.org/r/[email protected]
|
|
The current upstream method of having a function omit various tests is
to use the can_assume macro. Take the logic we had previously been using
and instead make it a can_assume(PERFECT) check within fdt_check_full
itself.
Reviewed-by: Simon Glass <[email protected]>
Signed-off-by: Tom Rini <[email protected]>
|
|
In the upstream project, the function fdt_check_full has been moved from
fdt_ro.c to its own file, fdt_check.c. This file is not included in the
Linux kernel copy and so has not been synced over. As we do need and use
the fdt_check_full function, bring that file over as of the current
upstream we are synced to. Remove our copy of this function from
fdt_ro.c and add fdt_check.o and 1-liner fdt_check.c where needed. Note
that for now, this will increase size in some cases as upstream does not
have a size reduction method here.
Reviewed-by: Simon Glass <[email protected]>
Signed-off-by: Tom Rini <[email protected]>
|
|
Enable USB fastboot support for downloading and flashing images via
the fastboot protocol.
Signed-off-by: Wadim Egorov <[email protected]>
|
|
For a compressed kernel_noload image, bootm_load_os() allocates a buffer
of ALIGN(image_len * 4, SZ_1M). The 4x factor is at the edge of what
modern compressors (zstd, xz) achieve on real kernels, so a
well-compressed vendor kernel can fail to boot at runtime with no
intervening warning.
Bump the headroom to 8x. The buffer is still bounded by the compressed
image size, and the SZ_1M alignment keeps the overhead below 1 MiB on
small kernels.
Suggested-by: Simon Glass <[email protected]>
Signed-off-by: Aristo Chen <[email protected]>
|
|
For a compressed kernel_noload image, bootm_load_os() allocates a
decompression buffer sized to ALIGN(image_len * 4, SZ_1M), assuming the
kernel compresses by no more than a factor of four. It then passes
CONFIG_SYS_BOOTM_LEN, rather than the size of that buffer, to
image_decomp() as the output limit. The decompressors honour the limit
they are given, so a kernel that decompresses to more than four times
its compressed size is written past the end of the allocated buffer and
corrupts adjacent memory.
Pass the allocation size to image_decomp() and handle_decomp_error() so
decompression stops at the buffer boundary and fails cleanly when the
image is too large, instead of overflowing. The regular non-noload
paths are unchanged and continue to use CONFIG_SYS_BOOTM_LEN. When the
failure is triggered by the smaller per-image buffer, print a note so
that handle_decomp_error()'s generic advice to increase
CONFIG_SYS_BOOTM_LEN does not mislead the reader.
Fixes: 69544c4fd8b1 ("bootm: Support kernel_noload with compression")
Reviewed-by: Simon Glass <[email protected]>
Signed-off-by: Aristo Chen <[email protected]>
|
|
OMAP4 support is present but there isn't any board using it.
Add minimal support for the Variscite OMAP4-SoM (debug console + boot
from SD card).
Use the ti/omap/omap4-var-stk-om44 device-tree from the Linux kernel. The
real representation of the SoM's hardware is located in
ti/omap/omap4-var-som-om44.dtsi included in it.
Set myself as maintainer for it.
Signed-off-by: Bastien Curutchet <[email protected]>
|
|
omap4 support was dropped by b0ee3fe642c ("arm: ti: Remove omap4 platform
support") because the supported boards hadn't done the conversion to
CONFIG_DM_I2C in time. It still exists some omap4-based products and
they could benefit from the latest U-Boot support for obvious security
reasons.
Revert part of b0ee3fe642c to introduce back a minimal support for the
omap4 platform.
Fix the checkpatch's warning/errors induced by this revert. Following
warnings are still present:
| arch/arm/include/asm/arch-omap4/clock.h:445: WARNING: added, moved or deleted file(s), does MAINTAINERS need updating?
| arch/arm/mach-omap2/omap4/hwinit.c:24: WARNING: Use 'if (IS_ENABLED(CONFIG...))' instead of '#if or #ifdef' where possible
| arch/arm/mach-omap2/omap4/sdram_elpida.c:142: CHECK: Avoid CamelCase: <tRPab>
| arch/arm/mach-omap2/omap4/sdram_elpida.c:143: CHECK: Avoid CamelCase: <tRCD>
| arch/arm/mach-omap2/omap4/sdram_elpida.c:144: CHECK: Avoid CamelCase: <tWR>
| arch/arm/mach-omap2/omap4/sdram_elpida.c:145: CHECK: Avoid CamelCase: <tRASmin>
| arch/arm/mach-omap2/omap4/sdram_elpida.c:146: CHECK: Avoid CamelCase: <tRRD>
| arch/arm/mach-omap2/omap4/sdram_elpida.c:147: CHECK: Avoid CamelCase: <tWTRx2>
| arch/arm/mach-omap2/omap4/sdram_elpida.c:148: CHECK: Avoid CamelCase: <tXSR>
| arch/arm/mach-omap2/omap4/sdram_elpida.c:149: CHECK: Avoid CamelCase: <tXPx2>
| arch/arm/mach-omap2/omap4/sdram_elpida.c:150: CHECK: Avoid CamelCase: <tRFCab>
| arch/arm/mach-omap2/omap4/sdram_elpida.c:151: CHECK: Avoid CamelCase: <tRTPx2>
| arch/arm/mach-omap2/omap4/sdram_elpida.c:152: CHECK: Avoid CamelCase: <tCKE>
| arch/arm/mach-omap2/omap4/sdram_elpida.c:153: CHECK: Avoid CamelCase: <tCKESR>
| arch/arm/mach-omap2/omap4/sdram_elpida.c:154: CHECK: Avoid CamelCase: <tZQCS>
| arch/arm/mach-omap2/omap4/sdram_elpida.c:155: CHECK: Avoid CamelCase: <tZQCL>
| arch/arm/mach-omap2/omap4/sdram_elpida.c:156: CHECK: Avoid CamelCase: <tZQINIT>
| arch/arm/mach-omap2/omap4/sdram_elpida.c:157: CHECK: Avoid CamelCase: <tDQSCKMAXx2>
| arch/arm/mach-omap2/omap4/sdram_elpida.c:158: CHECK: Avoid CamelCase: <tRASmax>
| arch/arm/mach-omap2/omap4/sdram_elpida.c:159: CHECK: Avoid CamelCase: <tFAW>
| arch/arm/mach-omap2/omap4/sdram_elpida.c:209: CHECK: Avoid CamelCase: <tRL>
| arch/arm/mach-omap2/omap4/sdram_elpida.c:210: CHECK: Avoid CamelCase: <tRP_AB>
| arch/arm/mach-omap2/omap4/sdram_elpida.c:213: CHECK: Avoid CamelCase: <tRAS_MIN>
| arch/arm/mach-omap2/omap4/sdram_elpida.c:215: CHECK: Avoid CamelCase: <tWTR>
| arch/arm/mach-omap2/omap4/sdram_elpida.c:216: CHECK: Avoid CamelCase: <tXP>
| arch/arm/mach-omap2/omap4/sdram_elpida.c:217: CHECK: Avoid CamelCase: <tRTP>
I didn't find an clean way to fix the "don't use #ifdef" warning as we
need to define the gpio_bank for the SPL build only.
For the CamelCase warnings, the incriminated attributes represent
timings, so IMHO, it is more readable with CamelCase.
Set myself as OMAP4 maintainer.
Signed-off-by: Bastien Curutchet <[email protected]>
|
|
This include file isn't used since the omap4 support has been dropped.
Since this support is about to be reintroduced, this file is going to be
used again. The upcoming support is minimal and doesn't include network,
therefore leaving PXE and DHCP in the BOOT_TARGET_DEVICES list would lead
to build errors.
Remove PXE and DHCP from the list of BOOT_TARGET_DEVICES.
Remove the LEGACY_MMC macros and the findfdt script that looks for
no-longer supported boards.
Remove the empty #ifdef XPL_BUILD
Signed-off-by: Bastien Curutchet <[email protected]>
|
|
The clock controller driven by this driver exists on other OMAP platforms
than the AM33xx. Yet, it uses functions provided by
arch/arm/mach-omap2/am33xx/clock.c making it unusable by other OMAPs.
Replace am33xx-specific do_{enable/disable}_clocks() with new static
functions implemented locally.
Replace the am33xx-specific clock header with the one shared by all OMAP
platforms.
Signed-off-by: Bastien Curutchet <[email protected]>
|
|
Lots of clock definitions are common to OMAP3, OMAP4 and OMAP5. So the
same macros are defined both in arch-am33xx/clock.h and in
arch-omap5/clock.h. Upcoming support for OMAP4 will again need the same
macros.
Group these common macro definitions into a common omap_clock header
shared across the OMAP2+ families.
Signed-off-by: Bastien Curutchet <[email protected]>
|
|
PRM_VC_I2C_CHANNEL_FREQ_KHZ is defined in omap5/clock.h but isn't really
related to clocks.
Since it's only used by mach-omap2/vc.c, move its definition there.
Signed-off-by: Bastien Curutchet <[email protected]>
|
|
set_one_region()"
Casey Connolly <[email protected]> says:
Currently trying to unmap a region results in slow and largely broken
behaviour as we unnecessarily split blocks and manually set thousands of
individual 4k pages instead of higher level blocks.
This series fixes the behaviour of set_one_region() so that it works
properly when called to unmap regions. See patch 4 for details.
Patches 1 & 2 improve the existing debug functionality, the pagetable
dumper will now print most explicitly unmapped regions (since they still
have their PA intact), as well as adding a new function which does a
very basic software TLB lookup to help with debugging.
Patch 3 de-duplicates some code by moving the loop that always surrounds
set_one_region() calls into its own function, this also helps with
readability in the calling functions.
Link: https://lore.kernel.org/r/[email protected]
|
|
As more platforms start ensuring they explicitly unmap reserved-memory
regions a few issues have appeared with how the existing dynamic mapping
code works. Fix these and get a small optimisation as well.
1. Teach pte_type() to actually respect the PTE_TYPE_VALID bit
2. Don't walk the TLB a second time if we call mmu_change_region_attr()
with PTE_TYPE_FAULT (since it would just be a slow nop)
3. Fix how set_one_region() decides to split blocks.
Today set_one_region() will always split blocks until it reaches the
smallest granule size (4k) and then update all of these pages. This
appears to be due to a big in how is_aligned() is implemented, since
it only evaluates to true if addr and size are both multiples of the
current granule size, so a mapping aligned to 2M which is 4M in size
will cleanly result in 2 blocks being set, but a mapping aligned to
2M which is 4M + 8k in size will result in blocks being split and 1026
individual pages being set.
While for the address it is correct to enforce that it is aligned to
the current granule size, we only need to check if the region size is
greater than the current granule size. This allows us to simplify our
second example above to only 4 entries being updated (assuming no blocks
have to be split) since we only need to update 2 blocks to map the first
4M, drastically improving the best-case performance.
In the case where the address is 4k aligned rather than 2M aligned we
will still be restricted to mapping 4k pages until we reach 2M alignment
where we could then map a larger 2M granule which previously would never
happen.
Signed-off-by: Casey Connolly <[email protected]>
Reviewed-by: Ilias Apalodimas <[email protected]>
|
|
This loop is duplicated 3 times, put it into its own function and call
it instead. This simplifies the logic in a few functions.
Reviewed-by: Ilias Apalodimas <[email protected]>
Signed-off-by: Casey Connolly <[email protected]>
|
|
When a region is explicitly unmapped (like with
mmu_change_region_attr(.... PTE_TYPE_FAULT)) the address translation
still remains but won't be used since the region is marked invalid.
Print these regions when we dump the pagetable to help with debugging.
Signed-off-by: Casey Connolly <[email protected]>
|
|
Implement a super basic software TLB walk which can look up a single
address in the TLB and print each stage of the translation. This is
helpful for debugging TLB issues and will be compiled out if unused.
Example output on QEMU aarch64:
Performing software TLB lookup of address 0x50100000 va_bits: 40
PTE: 0x47fe0000. addr[47:39]: 0x000 (offset 0x00000)
L0: 0x47fe0000 -> TABLE (0x47fe1000)
PTE: 0x47fe1000. addr[38:30]: 0x001 (offset 0x00008)
L1: 0x47fe1008 -> BLOCK (0x40000000)
[0x40000000 - 0x80000000]
Reviewed-by: Ilias Apalodimas <[email protected]>
Signed-off-by: Casey Connolly <[email protected]>
|
|
allocated buffer"
Aristo Chen <[email protected]> says:
For a compressed kernel_noload image, bootm_load_os() allocates a
decompression buffer of ALIGN(image_len * 4, SZ_1M) and then passes
CONFIG_SYS_BOOTM_LEN (typically 128 MiB on arm64) to image_decomp() as
the output limit. The decompressors honour whatever limit they are
given, so a kernel that decompresses to more than four times its
compressed size runs past the end of the allocated buffer and silently
corrupts adjacent memory.
A 4x compression ratio is at the edge of what modern compressors
(zstd, xz) achieve on real kernels, and is trivially exceeded by
crafted, highly compressible payloads, so this is reachable both
accidentally and intentionally. The overflow can land on already-loaded
boot artefacts (FDT, ramdisk, loadables), U-Boot's own data, or
memory-mapped device registers; the existing post-decompression overlap
check in bootm_load_os() only catches overlap with the FIT itself.
Patch 1 plumbs the actual allocation size through to image_decomp() and
handle_decomp_error() via a single decomp_len variable, so
decompression stops at the buffer boundary and fails cleanly when the
image is too large. The non-noload code path is unchanged and continues
to use CONFIG_SYS_BOOTM_LEN. A clarifying note is printed when the
failure is gated by the per-image buffer, so the generic
"increase CONFIG_SYS_BOOTM_LEN" advice does not mislead.
Patch 2 raises the noload-decompression headroom from 4x to 8x. The 4x
factor is at the edge of what zstd and xz achieve on real kernels, so
well-compressed vendor kernels can fail to boot at runtime once the
bound is enforced. 8x covers them comfortably while remaining bounded.
Patch 3 adds two sandbox py-tests against the per-image buffer at the
final 8x value: one that exceeds the buffer and must be rejected, and
one that matches the buffer exactly and must succeed (guarding the
boundary).
Tested on sandbox: both new tests pass; the existing
test_fit_compressed_images_load (which covers the load-address path)
and the other tests in test/py/tests/test_fit.py continue to pass.
Link: https://lore.kernel.org/r/[email protected]
|
