Skip to content
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.

Sign up for GitHub

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

Jump to bottom

tangier: fix SYST iteration for mmap #4

Merged
merged 1 commit into from
Jan 30, 2017
Merged

tangier: fix SYST iteration for mmap #4

merged 1 commit into from
Jan 30, 2017

Conversation

btashton
Copy link

Previous iteration logic did not increment the pointer in the table

Signed-off-by: Brennan Ashton brn@deako.com

tangier: fix SYST iteration for mmap
a42deb2 
Previous iteration logic did not increment the pointer in the table

Signed-off-by: Brennan Ashton <brn@deako.com>
@andy-shev
Copy link
Owner

If you have no objection I'll fold it into patch that introduced the change.

@andy-shev andy-shev merged commit f740512 into andy-shev:edison Jan 30, 2017
@andy-shev andy-shev self-requested a review January 30, 2017 12:37
@andy-shev andy-shev self-assigned this Jan 30, 2017
@btashton
Copy link
Author

Go ahead and roll it into that other patch. I just did it here to try and make it easy for you. Let me know what works best for other patches. I'm pushing down the path for my end goal so let me know if you have patches you want me to take a look at.

@andy-shev
Copy link
Owner

andy-shev commented Jan 30, 2017 •
edited
Loading

Yes the current case works pretty fine to me. You may also put into commit message that the patch should be folded to some previous one. It would be easier to me not to ask each time you submit something. I'm about to push an updated branch to Github. I do another refactoring to that code, please verify if it still works for you. (At least it works for me for official kernel)

After your confirmation I will fold them all.

@andy-shev
Copy link
Owner

andy-shev commented Jan 30, 2017 •
edited
Loading

@btashton
Regarding to the rest, my main goal regarding U-Boot on Edison is to bring ACPI (minimum) support there. So, if you have a chance to look into that direction it would be wonderful!

@btashton
Copy link
Author

I just verified #3 #1 with commit 7b27f52

Thank you!

@andy-shev
Copy link
Owner

Thanks! Folded and pushed.

andy-shev
andy-shev reviewed Jan 31, 2017
View reviewed changes
Copy link
Owner

@andy-shev andy-shev left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good!

andy-shev pushed a commit that referenced this pull request Jul 4, 2017
@stroese
fix: phy: marvell: cp110: fix the KR/SFI line 4 selector
d37f020 
This patch fixes the following:
1. KR/SFI on lane #4 mux selector is 0x2 and not 0x1
2. Comment typo

Signed-off-by: Rabeeh Khoury <rabeeh@solid-run.com>
Signed-off-by: Stefan Roese <sr@denx.de>
Signed-off-by: Igal Liberman <igall@marvell.com>
Reviewed-by: Stefan Roese <sr@denx.de>
andy-shev pushed a commit that referenced this pull request Aug 13, 2017
@trini
gpt: harden set_gpt_info() against non NULL-terminated strings
2fcaa41 
Strings read from devices may sometimes fail to be
NULL-terminated.   The functions in lib/string.c are subject to
failure in this case.   Protect against observed failures in
set_gpt_info() by switching to length-checking variants with a length
limit of the maximum possible partition table length.  At the same
time, add a few checks for NULL string pointers.

Here is an example as observed in sandbox under GDB:

    => gpt verify host 0 $partitions
    Program received signal SIGSEGV, Segmentation fault.
    0x0000000000477747 in strlen (s=0x0) at lib/string.c:267
    267             for (sc = s; *sc != '\0'; ++sc)
    (gdb) bt
    #0  0x0000000000477747 in strlen (s=0x0) at lib/string.c:267
    #1  0x00000000004140b2 in set_gpt_info (str_part=<optimized out>,
    str_disk_guid=str_disk_guid@entry=0x7fffffffdbe8, partitions=partitions@entry=0x7fffffffdbd8,
    parts_count=parts_count@entry=0x7fffffffdbcf "", dev_desc=<optimized out>) at cmd/gpt.c:415
    #2  0x00000000004145b9 in gpt_verify (str_part=<optimized out>, blk_dev_desc=0x7fffef09a9d0) at cmd/gpt.c:580
    #3  do_gpt (cmdtp=<optimized out>, flag=<optimized out>, argc=<optimized out>, argv=0x7fffef09a8f0)
    at cmd/gpt.c:783
    #4  0x00000000004295b0 in cmd_call (argv=0x7fffef09a8f0, argc=0x5, flag=<optimized out>,
    cmdtp=0x714e20 <_u_boot_list_2_cmd_2_gpt>) at common/command.c:500
    #5  cmd_process (flag=<optimized out>, argc=0x5, argv=0x7fffef09a8f0,
    repeatable=repeatable@entry=0x726c04 <flag_repeat>, ticks=ticks@entry=0x0) at common/command.c:539

Suggested-by: Lothar Waßmann <LW@karo-electronics.de>
Signed-off-by: Alison Chaiken <alison@peloton-tech.com>
staroselskii pushed a commit to staroselskii/u-boot that referenced this pull request Sep 1, 2018
@erosca @trini
common: avb_verify: Fix division by zero in mmc_byte_io()
e1904f4 
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
    andy-shev#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
    andy-shev#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
    andy-shev#12 0x46d34b in parse_file_outer common/cli_hush.c:3299
    andy-shev#13 0x4ad609 in cli_loop common/cli.c:217
    andy-shev#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>
andy-shev pushed a commit that referenced this pull request Apr 30, 2019
@erosca @sjg20
core: ofnode: Fix ASAN-reported stack-buffer-overflow in of_get_address
9bfacf2 
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/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>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@andy-shev andy-shev andy-shev left review comments

Assignees

@andy-shev andy-shev

Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
2 participants
@btashton @andy-shev