cancel
Showing results for 
Search instead for 
Did you mean: 

Archives Discussions

boxerab
Challenger

Stripping opencl binary corrupts file

After I generate a binary version of my kernel, I strip off .source, .llvmir and .amdil from ELF binary.

I am on windows 10 with latest crimson driver, with polaris 470.

The script I use can be found below ( I use mingw-64 tools to get objcopy and readelf executables)

Before I strip the binary, I can load it and create a kernel. After I strip the binary, my application crashes -CL_INVALID_KERNEL_NAME

error.

This works fine on my old system:

windows 7

latest crimson

cape verde HD 7700

Thanks,

Aaron

////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////

#!/bin/bash

#      ^^^^- important, not /bin/sh

# see http://developer.amd.com/knowledge-base/?ID=115 for more details

# define a regex, in ERE form, to extract the content you want in a match group

re='machine.*(0x[[:xdigit:]]{2,}) '

# iterate over files, putting each in $f

for f in *; do

        # don't operate on files we previously generated

        [[ $f = *.stripped ]] && continue

        # actually run readelf, taking first matching line

        m_line=$(readelf -aW "$f" | egrep -m 1 "$re")

    [[ $m_line =~ $re ]] || continue # check whether we match the regex

    # if we get here, the regex matched; copy the first match group into a variable

    code=${BASH_REMATCH[1]}

    # ...and use that variable in calling objcopy

    objcopy -I elf64-x86-64  -O elf64-x86-64 -R .source -R .llvmir -R .amdil \

          --alt-machine-code="$code" \

              "$f" "$f" >/dev/null 2>&1 || { echo "Objcopy failed!" >&2; }

             readelf -a "$f" | grep .source

             readelf -a "$f" | grep .llvmir

             readelf -a "$f" | grep .amdil

done

0 Likes
1 Solution

It's easier to use " -fno-bin-llvmir -fno-bin-amdil -fno-bin-source" options with clBuildProgram() to remove these sections rather than using external programs to strip them. However, it isn't the case for new ".brig" section implemented with "HSA-GCN" GPUs. Apparently there no switch to remove BRIG while it's quite huge. Moreover, it's pointless to keep BRIG within ELF -- HSA finalizer cannot be trusted, i. e. you're always need to check that compiled code producing correct results. I've faced several problems that .cl kernels compiles OK both for pre-HSA GPUs (which are GCN 1.0 like Tahiti) and HSA-GPUs (Ellesmere) but compiled HSA code is simply incorrect.

Anyway, looks like AMD drivers doesn't like section header table (e_shoff member within ELF header) in the beginning of the file, it must be placed at the very end. At least when I've wrote my own ELF stripper for AMD binaries this change (moving this table to the end) solves problem with loading stripped binaries.

View solution in original post

0 Likes
3 Replies

It's easier to use " -fno-bin-llvmir -fno-bin-amdil -fno-bin-source" options with clBuildProgram() to remove these sections rather than using external programs to strip them. However, it isn't the case for new ".brig" section implemented with "HSA-GCN" GPUs. Apparently there no switch to remove BRIG while it's quite huge. Moreover, it's pointless to keep BRIG within ELF -- HSA finalizer cannot be trusted, i. e. you're always need to check that compiled code producing correct results. I've faced several problems that .cl kernels compiles OK both for pre-HSA GPUs (which are GCN 1.0 like Tahiti) and HSA-GPUs (Ellesmere) but compiled HSA code is simply incorrect.

Anyway, looks like AMD drivers doesn't like section header table (e_shoff member within ELF header) in the beginning of the file, it must be placed at the very end. At least when I've wrote my own ELF stripper for AMD binaries this change (moving this table to the end) solves problem with loading stripped binaries.

0 Likes

Thanks! Didn't know about those flags.  The reason why I want to strip these sections out is to discourage reverse-engineering the binary.

Can .brig section be used for reverse engineering? It is an intermediate format, so perhaps yes?

Also, is there a way of successfully removing .brig ?

0 Likes

Well, looks like AMD simply forgot/don't care to add -fno-brig switch, so there no easy way to remove this .brig section (without writing your own program for that). And, yes, it's intermediate format, replacing AMDIL for GCN 1.1+ GPUs -- now it's HSAIL (and BRIG being something like llvmir).

Anyway, may be it's just me but I don't see a point to start reverse-engineering from IL code -- it's way too obfuscated/contains unnecessary things. Better to use disassembled ISA code itself... which you cannot strip anyway, so why bother?..

0 Likes