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.

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

Clang: ldelf fails to print mappings of shared library #3899

Open
jforissier opened this issue May 28, 2020 · 9 comments
Open

Clang: ldelf fails to print mappings of shared library #3899

jforissier opened this issue May 28, 2020 · 9 comments
Labels

Comments

@jforissier
Copy link
Contributor

jforissier commented May 28, 2020

xtest 1019 built with Clang 9.0.1 (10.0.0 and 11.0.0 are similar), QEMUv8:

$ xtest 1019
...
* regression_1019 Test dynamically linked TA
  regression_1019 OK
...

E/TC:? 0 TA panicked with code 0x0
E/LD:  Status of TA 5b9e0e40-2636-11e1-ad9e-0002a5d5c51b
E/LD:   arch: aarch64
E/LD:  region  0: va 0x40004000 pa 0x0e300000 size 0x002000 flags rw-s (ldelf)
E/LD:  region  1: va 0x40006000 pa 0x0e302000 size 0x008000 flags r-xs (ldelf)
E/LD:  region  2: va 0x4000e000 pa 0x0e30a000 size 0x001000 flags rw-s (ldelf)
E/LD:  region  3: va 0x4000f000 pa 0x0e30b000 size 0x003000 flags rw-s (ldelf)
E/LD:  region  4: va 0x40012000 pa 0x0e30e000 size 0x001000 flags r--s
E/LD:  region  5: va 0x40013000 pa 0x0e405000 size 0x003000 flags rw-s (stack)
E/LD:  assertion 'maps[map_idx].sz == sz' failed at ldelf/ta_elf.c:1230 in ta_elf_print_mappings()
E/TC:? 0
E/TC:? 0 TA panicked with code 0xffff0000
E/TC:? 0
E/TC:? 0 Can't unwind invalid user stack 0x40005d40
E/TC:? 0 dump_state_ldelf_dbg:415 ldelf dump function panicked
E/TC:? 0  region  0: va 0x0000000040000000 pa 0x000000000e102000 size 0x002000 flags ---R-X
E/TC:? 0  region  1: va 0x0000000040002000 pa 0x000000000e183000 size 0x001000 flags ---RW-
E/TC:? 0  region  2: va 0x0000000040004000 pa 0x000000000e300000 size 0x002000 flags rw-RW-
E/TC:? 0  region  3: va 0x0000000040006000 pa 0x000000000e302000 size 0x008000 flags r-x---
E/TC:? 0  region  4: va 0x000000004000e000 pa 0x000000000e30a000 size 0x001000 flags rw-RW-
E/TC:? 0  region  5: va 0x000000004000f000 pa 0x000000000e30b000 size 0x003000 flags rw-RW-
E/TC:? 0  region  6: va 0x0000000040012000 pa 0x000000000e30e000 size 0x001000 flags r--R--
E/TC:? 0  region  7: va 0x0000000040013000 pa 0x000000000e405000 size 0x003000 flags rw-RW-
E/TC:? 0  region  8: va 0x0000000040030000 pa 0x000000000e408000 size 0x001000 flags r-xR--
E/TC:? 0  region  9: va 0x0000000040031000 pa 0x000000000e409000 size 0x001000 flags r--R--
E/TC:? 0  region 10: va 0x0000000040032000 pa 0x000000000e40a000 size 0x001000 flags r-xR--
E/TC:? 0  region 11: va 0x0000000040033000 pa 0x000000000e40b000 size 0x001000 flags rw-RW-
E/TC:? 0  region 12: va 0x0000000040034000 pa 0x000000000e40c000 size 0x001000 flags rw-RW-
E/TC:? 0  region 13: va 0x000000004006b000 pa 0x000000000e30f000 size 0x011000 flags r-xR--
E/TC:? 0  region 14: va 0x000000004007c000 pa 0x000000000e320000 size 0x0e5000 flags rw-RW-
D/TC:? 0 user_ta_enter:167 tee_user_ta_enter: TA panicked with code 0x0

The test is succesful, but the secure console should normally print complete debugging information i.e., TA mappings followed by a call stack. Here ldelf meets an unexpected condition and stops the dump.

The program headers of the shared library:

$ aarch64-linux-gnu-readelf -l ../out-br/build/optee_test-1.0/ta
/os_test_lib/out/ffd2bded-ab7d-4988-95ee-e4962fff7154.elf

Elf file type is DYN (Shared object file)
Entry point 0x2000
There are 8 program headers, starting at offset 64

Program Headers:
  Type           Offset             VirtAddr           PhysAddr
                 FileSiz            MemSiz              Flags  Align
  PHDR           0x0000000000000040 0x0000000000000040 0x0000000000000040
                 0x00000000000001c0 0x00000000000001c0  R      0x8
  LOAD           0x0000000000000000 0x0000000000000000 0x0000000000000000
                 0x0000000000001110 0x0000000000001110  R      0x1000
  LOAD           0x0000000000002000 0x0000000000002000 0x0000000000002000
                 0x0000000000000340 0x0000000000000340  R E    0x1000
  LOAD           0x0000000000003000 0x0000000000003000 0x0000000000003000
                 0x0000000000000130 0x0000000000000130  RW     0x1000
  LOAD           0x0000000000004000 0x0000000000004000 0x0000000000004000
                 0x0000000000000030 0x0000000000000030  RW     0x1000
  DYNAMIC        0x0000000000003008 0x0000000000003008 0x0000000000003008
                 0x0000000000000120 0x0000000000000120  RW     0x8
  GNU_RELRO      0x0000000000003000 0x0000000000003000 0x0000000000003000
                 0x0000000000000130 0x0000000000001000  R      0x1
  GNU_STACK      0x0000000000000000 0x0000000000000000 0x0000000000000000
                 0x0000000000000000 0x0000000000000000  RW     0x0

 Section to Segment mapping:
  Segment Sections...
   00
   01     .dynsym .gnu.hash .hash .dynstr .rela.dyn .rela.plt
   02     .text .plt
   03     .init_array .dynamic .got
   04     .got.plt
   05     .dynamic
   06     .init_array .dynamic .got
   07
@jforissier jforissier added the bug label May 28, 2020
@github-actions
Copy link

This issue has been marked as a stale issue because it has been open (more than) 30 days with no activity. Remove the stale label or add a comment saying that you would like to have the label removed otherwise this issue will automatically be closed in 5 days. Note, that you can always re-open a closed issue at any time.

@github-actions github-actions bot added the Stale label Jun 28, 2020
@jforissier jforissier removed the Stale label Jun 28, 2020
@jforissier jforissier changed the title Clang 9.0.1, Clang 10: ldelf fails to print mappings of shared library Clang: ldelf fails to print mappings of shared library Apr 16, 2021
@ZheTingLiu
Copy link
Contributor

Hi @jforissier

I also encounter this problem after changing toolchain from GCC to Clang 9.0.1. Do you start to work on this issue?
If I want to try to solve this issue, how I can start it. I don't see other opened issues that are about this problem.
I think this problem will make us hard to debug when TA panic or something like that.

@jforissier
Copy link
Contributor Author

Hi @ZTingLiu,

I also encounter this problem after changing toolchain from GCC to Clang 9.0.1. Do you start to work on this issue?

No. Unfortunately I don't know this part of the code very well :-/

If I want to try to solve this issue, how I can start it. I don't see other opened issues that are about this problem.
I think this problem will make us hard to debug when TA panic or something like that.

I agree. What is happening here is that ldelf was implemented and tested mostly based on the output of GCC, and I think some assumptions were made that do not always hold true. @jenswi-linaro any comments on how to troubleshoot this?

@jenswi-linaro
Copy link
Contributor

The maps argument to ta_elf_print_mappings() is from OP-TEE Core while the segments are Ldelfs view of things. Ldelf know nothing of the mapped parameters so that part is taken from maps. The two lists should agree in principle and that's what the assert() is about.

The check around some corner case just before the failing assert() looks a bit suspicious perhaps there's easier more relaxed way of skipping the entries in maps that are supposed to be covered by the segments instead.

@ZheTingLiu
Copy link
Contributor

Hi
Does this error case only occur in OS_TEST TA? There is panic test in xtest 6010, but no this error.
Maybe the problem is in os_test_lib and os_test_lib_dl. I am not sure about that. This is only my guess.

@jforissier
Copy link
Contributor Author

@ZTingLiu you are right, the problem is only with shared libraries.

@ZheTingLiu
Copy link
Contributor

ZheTingLiu commented Jun 24, 2021

@jforissier
Sorry, I have another question. The share libraries that you mean are all share libraries instead of os_test_lib and os_test_lib_dl?

@jforissier
Copy link
Contributor Author

@ZTingLiu yes.

@ZheTingLiu
Copy link
Contributor

Hi
If I comment out the assert condition and let ldelf keep going, I can get correct stack dump.
Also, the assert only happens at first region at each share libraries.
Is there any risk if I comment out the assert condition?
(https://github.com/OP-TEE/optee_os/blob/master/ldelf/ta_elf.c#L1358)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants