Verify Integration

Static Verification of Integration

Executables produced on any target will contain the following section .txtrp and can be used to verify the protections have been applied. Use readelf to check that the section .txtrp has content.

readelf -x .txtrp <binary name> | grep 0x -m3

For example, with a hello_world binary built with RunSafe Protect, readelf will return the following output:

$ readelf -x .txtrp ./hello_world | grep 0x -m3
0x0000200e 01d10b00 4065f0ff ffffffff ff020000 ....@e..........
0x0000201e 0609027c 09047c16 046bf0ff ffffffff ...|..|..k......
0x0000202e ff020000 0c0d2a7c 072a7c07 2a7c0504 ......*|.*|.*|..

If RunSafe Protect was not successfuly applied, it would return this error:

readelf: Warning: Section '.txtrp' was not dumped because it does not exist!

Runtime Verification of Integration

Most deployments of RunSafe Protect have the ability to produce debug logging to see protection being applied by setting the LFR_DEBUG_LEVEL environment variable to a value from 1-10. When set to 1, users can verify that randomization is occuring by inspecting the debug output looking for Finished randomizing.

$ LFR_DEBUG_LEVEL=1 ./hello_world
Module@0x7ffca1049a30 base:0x5582e3148000 GOT:0x5582e314c000 .eh_frame_hdr:0x5582e314a110 static:0
Module path:'./hello_world'
Checking for restricted context in lfr.toml
LFR SELinux: CANT read /sys/fs/selinux/
LFR SELinux: Disabled
Module@0x7ffca1049920 base:0x5582e3148000 GOT:0x5582e314c000 .eh_frame_hdr:0x5582e314a110 static:0
Module path:'./hello_world'
Module@0x7ffca1049920 sec@0x5582e3149070[400] TRaP@0x5582e314a012[251]
GOT relocations found: 5
Found exec section @0x5582e3149070[400]
Building functions...
Shuffling functions...
Divcode size:379 Old: 400
Module Name: ./hello_world Module trampoline_counter:0
Divcode@0x7f23523a4000
New init:0x5582e3149000 entry:0x5582e3149202
.eh_frame_hdr found 6 entries
Updating Eh_frame (Mod args 0x7ffca1049c80, dynamic 0x5582e314bde0)
Calling unmap on 0x7f23523a4000 which is size 379
Finished randomizing
Hello, world!

Troubleshooting Integration Issues

If static or runtime verification do not show successful integration, there are a few common causes.

Missing lfr-helper

When static verification fails to find the .txtrp section, make sure that lfr-helper was applied to the step of the build process that produces that binary.

Absolute Paths to Build Tools

If lfr-helper is present, inspect your build script/system to see if the compiler, linker, or other build tools are invoked using absolute paths (i.e. /usr/bin/gcc) instead of by name (gcc) and change the invocation to use the build tool name instead of an absolute path to the tool.

If that is not feasible due to other build system constraints, reach out to [email protected] and we can walk you through some simple build system tweaks that will allow you to continue to use absolute paths.

Build System Cleans $PATH

Some build systems sanitize or override the PATH variable, which can break the lfr-helper integration. In those cases, modify your build system to add /usr/bin/alkemist/lfr/scripts to the front of your PATH variable.

Build System Overrides CFLAGS/CXXFLAGS/LDFLAGS

Some build systems hardcode CFLAGS, CXXFLAGS, or LDFLAGS (or similar). In those cases, add the following flags to any environment variables that set the build flags:

-ffunction-sections -fdata-sections -fPIC -B/usr/bin/alkemist/lfr/scripts