[SWDEV-563823][Compiler-rt][ASan] Simplify API Logic 'asan_hsa_amd_ipc_memory_create'.

[ampandey-AMD]

• Use reinterpret_cast for pointer arithmetic.
• Add sanitizer interception logic for api 'hsa_amd_pointer_info'.
• Allow only valid values of ptr and len in non-ASan mode.
  • ptr == Actual agentBaseAddress && len ==
    original_len_used_in_alloc
• Allow only valid values of ptr and len in ASan mode. pinfo resembles
  to pointer info extracted in GetBlockBegin function.
  • ptr == pinfo.agentBaseAddress && len == pinfo.sizeInBytes
  • ptr == original_ptr_returned_by_ASAN && len ==
    original_len_used_in_alloc

[z1-cciauto]

PSDB Link: https://compiler-ci.amd.com/job/compiler-psdb-amd-staging/2637

[z1-cciauto]

PSDB Link: https://compiler-ci.amd.com/job/compiler-psdb-amd-staging/2638

[z1-cciauto]

PSDB Link: https://compiler-ci.amd.com/job/compiler-psdb-amd-staging/2639

[b-sumner]

Does the test application in the ticket print the same "base" "len" and "end" as the uninstrumented version (taking into account address randomization)?

[ampandey-AMD]

Does the test application in the ticket print the same "base" "len" and "end" as the uninstrumented version (taking into account address randomization)?

Yes. If we include the current fix with/without intercepting hsa_amd_pointer_info.

Non-Instrumented O/P

hsa_amd_pointer_info: test_buff 0x7c947a815000 base 0x7c947a814000 len 16384 end 0x7c947a818000
hsa_amd_ipc_memory_create: handle: [7a814000][7c94][395301][0][4][0][0][5325e42b]

Instrumented O/P

hsa_amd_pointer_info: test_buff 0x7ef7c9509000 base 0x7ef7c9508000 len 16384 end 0x7ef7c950c000
hsa_amd_ipc_memory_create: handle: [c9508000][7ef7][394f4c][0][4][0][0][3a761d78]

[b-sumner]

But the output in the ticket, when -fsanitize=address is not used is:

hsa_amd_pointer_info: test_buff 0x7f3df2400000 base 0x7f3df2400000 len 1024 end 0x7f3df2400400

Here the buffer and the base are the same, and len is 1024. Shouldn't our intercepted version of hsa_amd_pointer_info return the same buffer and base, and a len of 1024 instead of 16384?

[ampandey-AMD]

But the output in the ticket, when -fsanitize=address is not used is:

hsa_amd_pointer_info: test_buff 0x7f3df2400000 base 0x7f3df2400000 len 1024 end 0x7f3df2400400

Here the buffer and the base are the same, and len is 1024. Shouldn't our intercepted version of hsa_amd_pointer_info return the same buffer and base, and a len of 1024 instead of 16384?

Hi @b-sumner , Ok in my previous o/p, the problem was because of LD_LIBRARY_PATH set to asan instrumented libraries and I compiled non-instrumented o/p without flags -fsanitize=address -shared-libsan. So my executable was actually linked to asan instrumented libraries of rocr and hipamd.

If I avoid adding the /opt/rocm/llvm/lib/asan or /opt/rocm/lib/asan from my LD_LIBRARY_PATH, then I am getting this non-instrumented O/P

hsa_amd_pointer_info: test_buff 0x7b6a28800000 base 0x7b6a28800000 len 1024 end 0x7b6a28800400
hsa_amd_ipc_memory_create: handle: [28800000][7b6a][1feb9][0][4][0][80000000][3d9ec7b6]

I think instrumentation here is not kind of problem, we enable the asan interception of those hsa_amd* api calls in the asanified libraries only as our code is bounded by preprocessor macro SANITIZER_AMDGPU. We actually don't try to instrument the hsa_api* calls itself.

[ampandey-AMD]

Hi @b-sumner,
So I tested locally by removing the asan interception code of hsa_amd_pointer_info.

Here are the results without asan_hsa_amd_pointer_info implemented.

Instrumented (ASan enabled via -fsanitize=address -shared-libsan with LD_LIBRARY_PATH set to path/to/lib/asan)

hsa_amd_pointer_info: test_buff 0x75863cea5000 base 0x75863cea4000 len 16384 end 0x75863cea8000
hsa_amd_ipc_memory_create: handle: [3cea4000][7586][22d9b][0][4][0][0][51fdf52f]

Non-Instrumented (ASan disabled with LD_LIBRARY_PATH not set to /path/to/lib/asan)

hsa_amd_pointer_info: test_buff 0x74bd90c00000 base 0x74bd90c00000 len 1024 end 0x74bd90c00400
hsa_amd_ipc_memory_create: handle: [90c00000][74bd][22cd4][0][4][0][80000000][3a14da89]

[b-sumner]

Thanks! My thinking is that in order to provide acceptable information to our interception of hsa_amd_ipc_memory_create, our interception of hsa_amd_pointer_info should return the same base, len, and end as observed when the application is not built with instrumentation (or running instrumented libraries). But I would like to hear @bing-ma's take on this.

[z1-cciauto]

PSDB Link: https://compiler-ci.amd.com/job/compiler-psdb-amd-staging/2664

[z1-cciauto]

PSDB Link: https://compiler-ci.amd.com/job/compiler-psdb-amd-staging/2665

[z1-cciauto]

PSDB Link: https://compiler-ci.amd.com/job/compiler-psdb-amd-staging/2666

[z1-cciauto]

PSDB Link: https://compiler-ci.amd.com/job/compiler-psdb-amd-staging/2678

[z1-cciauto]

PSDB Link: https://compiler-ci.amd.com/job/compiler-psdb-amd-staging/2679

[z1-cciauto]

PSDB Link: https://compiler-ci.amd.com/job/compiler-psdb-amd-staging/2680

[z1-cciauto]

PSDB Link: https://compiler-ci.amd.com/job/compiler-psdb-amd-staging/2709

[z1-cciauto]

PSDB Link: https://compiler-ci.amd.com/job/compiler-psdb-amd-staging/2710

[b-sumner]

Do we not need to guard against null ptr_ here like we do in ipc create?

[ampandey-AMD]

If ptr_ == nullptr then if condition at line number 1559 will fail.

Then if condition at line number 1562 for first condition status == HSA_STATUS_SUCCESS would fail ambiguously as status is not getting set up with default value. I think we need to initialize this with status=HSA_STATUS_ERROR_NOT_INITIALIZED. Is that ok @b-sumner && @bing-ma?

[ampandey-AMD]

I default initialized status with value HSA_STATUS_ERROR_NOT_INITIALIZED in 00898ca.

[z1-cciauto]

PSDB Link: https://compiler-ci.amd.com/job/compiler-psdb-amd-staging/2737