-
Notifications
You must be signed in to change notification settings - Fork 4k
drivers/crypto/fsl: flush cache after performing byte swap on descriptor #8
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Closed
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
trini
pushed a commit
that referenced
this pull request
Aug 24, 2018
Compiling U-Boot with ubsan/asan libraries and running it in sandbox may lead to below backtrace: => avb init 0 => avb verify ## Android Verified Boot 2.0 version 1.1.0 read_is_device_unlocked not supported yet common/avb_verify.c:407:31: runtime error: division by zero AddressSanitizer:DEADLYSIGNAL Reviewed-by: Igor Opaniuk <igor.opaniuk@linaro.org> ============================ 8000 ===================================== ==9388==ERROR: AddressSanitizer: FPE on unknown address 0x0000004b467f \ (pc 0x0000004b467f bp 0x000000000000 sp 0x7ffd899fe150 T0) #0 0x4b467e in mmc_byte_io common/avb_verify.c:407 #1 0x4b4c47 in mmc_byte_io common/avb_verify.c:532 #2 0x4b4c47 in read_from_partition common/avb_verify.c:533 #3 0x69dc0d in load_and_verify_vbmeta lib/libavb/avb_slot_verify.c:560 #4 0x6a1ee6 in avb_slot_verify lib/libavb/avb_slot_verify.c:1139 #5 0x45dabd in do_avb_verify_part cmd/avb.c:245 #6 0x4af77c in cmd_call common/command.c:499 #7 0x4af77c in cmd_process common/command.c:538 #8 0x46bafc in run_pipe_real common/cli_hush.c:1677 #9 0x46bafc in run_list_real common/cli_hush.c:1875 #10 0x46c780 in run_list common/cli_hush.c:2024 #11 0x46c780 in parse_stream_outer common/cli_hush.c:3216 #12 0x46d34b in parse_file_outer common/cli_hush.c:3299 #13 0x4ad609 in cli_loop common/cli.c:217 #14 0x4625ae in main_loop common/main.c:65 #15 0x46f2d1 in run_main_loop common/board_r.c:648 #16 0x640253 in initcall_run_list lib/initcall.c:30 #17 0x46f9d0 in board_init_r common/board_r.c:879 #18 0x40539b in main arch/sandbox/cpu/start.c:321 #19 0x7fa94925f82f in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x2082f) #20 0x408908 in _start (/srv/R/u-boot-master/u-boot+0x408908) AddressSanitizer can not provide additional info. SUMMARY: AddressSanitizer: FPE common/avb_verify.c:407 in mmc_byte_io ==9388==ABORTING Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com>
u-boot community does not handle PRs on GitHub, please read https://github.com/u-boot/u-boot/blob/master/README |
trini
pushed a commit
that referenced
this pull request
Apr 14, 2019
v2019.04-rc3 sandbox U-Boot fails to boot when compiled with -fsanitize=address and linked against -lasan, reporting [1]. Git bisecting shows that the issue is contributed by v2019.01 commit 1678754 ("core: ofnode: Fix ofnode_get_addr_index function"). The root cause seems to be the mismatch between sizeof(u64) and sizeof(fdt_size_t) on sandbox. Luckily, thanks to the fact that the size argument of both of_get_address() and fdtdec_get_addr_size_fixed() is optional, we can pass NULL in its place, avoiding the problem. [1] Backtrace reported by ASAN (gcc 8.1.0): $> ./u-boot -d arch/sandbox/dts/sandbox.dtb [..] Reviewed-by: Simon Glass <sjg@chromium.org> ================================================================= ==10998==ERROR: AddressSanitizer: stack-buffer-overflow on address 0x7ffcc2331140 at pc 0x0000004eeeb0 bp 0x7ffcc2330f80 sp 0x7ffcc2330f70 WRITE of size 8 at 0x7ffcc2331140 thread T0 #0 0x4eeeaf in of_get_address drivers/core/of_addr.c:154 #1 0x4f7441 in ofnode_get_addr_index drivers/core/ofnode.c:263 #2 0x5b2a78 in sb_eth_ofdata_to_platdata drivers/net/sandbox.c:422 #3 0x4dccd8 in device_probe drivers/core/device.c:407 #4 0x753170 in eth_initialize net/eth-uclass.c:428 #5 0x47d9bf in initr_net common/board_r.c:557 #6 0x6bcfa7 in initcall_run_list lib/initcall.c:30 #7 0x47e1fe in board_init_r common/board_r.c:859 #8 0x4060e5 in main arch/sandbox/cpu/start.c:356 #9 0x7fb8d135482f in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x2082f) #10 0x40a3a8 in _start (/path/to/u-boot/u-boot+0x40a3a8) Address 0x7ffcc2331140 is located in stack of thread T0 at offset 32 in frame #0 0x4f72b8 in ofnode_get_addr_index drivers/ 8000 core/ofnode.c:255 This frame has 3 object(s): [32, 36) 'size' <== Memory access at offset 32 partially overflows this variable [96, 100) 'flags' [160, 168) 'node' HINT: this may be a false positive if your program uses some custom stack unwind mechanism or swapcontext (longjmp and C++ exceptions *are* supported) SUMMARY: AddressSanitizer: stack-buffer-overflow drivers/core/of_addr.c:154 in of_get_address Shadow bytes around the buggy address: 0x10001845e1d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x10001845e1e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x10001845e1f0: 00 00 00 00 00 00 00 00 00 00 00 00 f1 f1 f1 f1 0x10001845e200: 04 f2 f2 f2 f2 f2 f2 f2 04 f2 f2 f2 f2 f2 f2 f2 0x10001845e210: 04 f2 f2 f2 f3 f3 f3 f3 00 00 00 00 00 00 00 00 =>0x10001845e220: 00 00 00 00 f1 f1 f1 f1[04]f2 f2 f2 f2 f2 f2 f2 0x10001845e230: 04 f2 f2 f2 f2 f2 f2 f2 00 f2 f2 f2 f3 f3 f3 f3 0x10001845e240: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x10001845e250: 00 00 00 00 f1 f1 f1 f1 00 00 f2 f2 f3 f3 f3 f3 0x10001845e260: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 f1 f1 0x10001845e270: f1 f1 00 f2 f2 f2 f3 f3 f3 f3 00 00 00 00 00 00 Shadow byte legend (one shadow byte represents 8 application bytes): Addressable: 00 Partially addressable: 01 02 03 04 05 06 07 Heap left redzone: fa Freed heap region: fd Stack left redzone: f1 Stack mid redzone: f2 Stack right redzone: f3 Stack after return: f5 Stack use after scope: f8 Global redzone: f9 Global init order: f6 Poisoned by user: f7 Container overflow: fc Array cookie: ac Intra object redzone: bb ASan internal: fe Left alloca redzone: ca Right alloca redzone: cb ==10998==ABORTING 'To' list: git log --since=1year drivers/core/ofnode.c | grep "\-by: .*@" | \ sed 's/.*-by: //' | sort | uniq -c | sort -rn 10 Simon Glass <sjg@chromium.org> 3 Mario Six <mario.six@gdsys.cc> 2 Martin Fuzzey <mfuzzey@parkeon.com> 2 Marek Vasut <marek.vasut+renesas@gmail.com> 1 Tom Rini <trini@konsulko.com> 1 Masahiro Yamada <yamada.masahiro@socionext.com> 1 Keerthy <j-keerthy@ti.com> 1 Jens Wiklander <jens.wiklander@linaro.org> 1 Bin Meng <bmeng.cn@gmail.com> Fixes: 1678754 ("core: ofnode: Fix ofnode_get_addr_index function") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com>
fbertux
pushed a commit
to OSSystems/u-boot
that referenced
this pull request
Sep 29, 2020
Compiling U-Boot with ubsan/asan libraries and running it in sandbox may lead to below backtrace: => avb init 0 => avb verify ## Android Verified Boot 2.0 version 1.1.0 read_is_device_unlocked not supported yet common/avb_verify.c:407:31: runtime error: division by zero AddressSanitizer:DEADLYSIGNAL Reviewed-by: Igor Opaniuk <igor.opaniuk@linaro.org> ================================================================= ==9388==ERROR: AddressSanitizer: FPE on unknown address 0x0000004b467f \ (pc 0x0000004b467f bp 0x000000000000 sp 0x7ffd899fe150 T0) #0 0x4b467e in mmc_byte_io common/avb_verify.c:407 #1 0x4b4c47 in mmc_byte_io common/avb_verify.c:532 #2 0x4b4c47 in read_from_partition common/avb_verify.c:533 #3 0x69dc0d in load_and_verify_vbmeta lib/libavb/avb_slot_verify.c:560 #4 0x6a1ee6 in avb_slot_verify lib/libavb/avb_slot_verify.c:1139 #5 0x45dabd in do_avb_verify_part cmd/avb.c:245 #6 0x4af77c in cmd_call common/command.c:499 u-boot#7 0x4af77c in cmd_process common/command.c:538 u-boot#8 0x46bafc in run_pipe_real common/cli_hush.c:1677 u-boot#9 0x46bafc in run_list_real common/cli_hush.c:1875 u-boot#10 0x46c780 in run_list common/cli_hush.c:2024 u-boot#11 0x46c780 in parse_stream_outer common/cli_hush.c:3216 u-boot#12 0x46d34b in parse_file_outer common/cli_hush.c:3299 u-boot#13 0x4ad609 in cli_loop common/cli.c:217 u-boot#14 0x4625ae in main_loop common/main.c:65 u-boot#15 0x46f2d1 in run_main_loop common/board_r.c:648 u-boot#16 0x640253 in initcall_run_list lib/initcall.c:30 u-boot#17 0x46f9d0 in board_init_r common/board_r.c:879 u-boot#18 0x40539b in main arch/sandbox/cpu/start.c:321 u-boot#19 0x7fa94925f82f in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x2082f) u-boot#20 0x408908 in _start (/srv/R/u-boot-master/u-boot+0x408908) AddressSanitizer can not provide additional info. SUMMARY: AddressSanitizer: FPE common/avb_verify.c:407 in mmc_byte_io ==9388==ABORTING Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com>
trini
pushed a commit
that referenced
this pull request
Jan 20, 2021
Atish reports that on RISC-V, accessing the EFI variables causes a kernel panic. An objdump of the file verifies that, since the global pointer for efi_var_buf ends up in .GOT section which is not mapped in virtual address space for Linux. <snip of efi_var_mem_find> 0000000000000084 <efi_var_mem_find>: 84: 715d addi sp,sp,-80 * objdump -dr 0000000000000086 <.LCFI2>: 86: e0a2 sd s0,64(sp) 88: fc26 sd s1,56(sp) 8a: e486 sd ra,72(sp) 8c: f84a sd s2,48(sp) 8e: f44e sd s3,40(sp) 90: f052 sd s4,32(sp) 92: ec56 sd s5,24(sp) 94: 00000497 auipc s1,0x0 94: R_RISCV_GOT_HI20 efi_var_buf 98: 0004b483 ld s1,0(s1) # 94 <.LCFI2+0xe> 98: R_RISCV_PCREL_LO12_I .L0 98: R_RISCV_RELAX *ABS* * objdump -t 0000000000000084 g F .text.efi_runtime 00000000000000b8 efi_var_mem_find With the patch applied: * objdump -dr 0000000000000086 <.LCFI2>: 86: e0a2 sd s0,64(sp) 88: fc26 sd s1,56(sp) 8a: e486 sd ra,72(sp) 8c: f84a sd s2,48(sp) 8e: f44e sd s3,40(sp) 90: f052 sd s4,32(sp) 92: ec56 sd s5,24(sp) 94: 00000497 auipc s1,0x0 94: R_RISCV_PCREL_HI20 .LANCHOR0 94: R_RISCV_RELAX *ABS* 98: 00048493 mv s1,s1 98: R_RISCV_PCREL_LO12_I .L0 98: R_RISCV_RELAX *ABS* * objdump -t 0000000000000008 l O .data.efi_runtime 0000000000000008 efi_var_buf On arm64 this works, because there's no .GOT entries for this and everything is converted to relative references. * objdump -dr (identical pre-post patch, only the new function shows up) 00000000000000b4 <efi_var_mem_find>: b4: aa0003ee mov x14, x0 b8: 9000000a adrp x10, 0 <efi_var_mem_compare> b8: R_AARCH64_ADR_PREL_PG_HI21 .data.efi_runtime bc: 91000140 add x0, x10, #0x0 bc: R_AARCH64_ADD_ABS_LO12_NC .data.efi_runtime c0: aa0103ed mov x13, x1 c4: 79400021 ldrh w1, [x1] c8: aa0203eb mov x11, x2 cc: f9400400 ldr x0, [x0, #8] d0: b940100c ldr w12, [x0, #16] d4: 8b0c000c add x12, x0, x12 So let's switch efi_var_buf to static and create a helper function for anyone that needs to update it. Fixes: e01aed4 ("efi_loader: Enable run-time variable support for tee based variables") Reported-by: Atish Patra <atishp@atishpatra.org> Tested-by: Atish Patra <atish.patra@wdc.com> Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
samueldr
pushed a commit
to samueldr/u-boot
that referenced
this pull request
Mar 27, 2023
Call trace: PC: [< 00a7b36c >] printch+0x3c/0x68 /home4/cjh/uboot-nextdev/drivers/serial/ns16550.c:280 LR: [< 00a247e4 >] puts+0x1c/0x30 /home4/cjh/uboot-nextdev/common/console.c:592 Stack: [< 00a7b36c >] printch+0x3c/0x68 [< 00ab337c >] printf+0x90/0xb4 [< 00a036e4 >] rk_board_fdt_fixup+0x30/0x1a8 [< 00a01f10 >] arch_fixup_fdt+0xc/0x94 [< 00a2aa28 >] image_setup_libfdt+0x14/0x114 [< 00a26d1c >] image_setup_linux+0x4c/0x6c ...... PC Surrounding Instructions: a7b358: 528001a2 mov w2, #0xd // u-boot#13 a7b35c: b9000022 str w2, [x1] a7b360: b4000192 cbz x18, a7b390 <printch+0x60> a7b364: f9400642 ldr x2, [x18,u-boot#8] a7b368: 373000e2 tbnz w2, u-boot#6, a7b384 <printch+0x54> a7b36c: f940d242 ldr x2, [x18,u-boot#416] a7b370: b4000102 cbz x2, a7b390 <printch+0x60> a7b374: f940d241 ldr x1, [x18,u-boot#416] a7b378: b9401422 ldr w2, [x1,u-boot#20] a7b37c: 362fffe2 tbz w2, u-boot#5, a7b378 <printch+0x48> a7b380: b9000020 str w0, [x1] Signed-off-by: Joseph Chen <chenjh@rock-chips.com> Change-Id: I48391165094708dd86eeeabea09739a4c14fcf6f
charkear
referenced
this pull request
in HewlettPackard/gxp-uboot
Jun 28, 2023
Additional features for the recovery process
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Existing code fails to flush the cache after performing an optional byte-swap to match the SEC endianess. This code seems to work if the swap is not necessary, but causes failures on platforms where the swap is needed.
I used the existing paradigm of start/end calculation followed by a call to flush_dcache_range().