tudinfse / sgxbounds Goto Github PK

I have done this:

1. write a test.c
   2.clang -c -emit-llvm runtime.c test.c
   3.llvm-link runtime.bc test.bc > test-runtime.bc
   4.opt -load ./sgxbouds.so < test-runtime.bc > test-sgx.bc -sgxbouds -enable-opt -debug
   5.clang -c -emit-llvm wrappers.c
   6.llvm-link test-sgx.bc wrappers.bc >test-result.bc
   7,lli test-result.bc

when I doing the 7 step, It assert some errors:
1.function 'get_heap_end' which could not be resolved!
2.function 'malloc_real' which could not be resolved!

It seems the sgxbouds does not contain those functions realize,only contains declarations.
And I know malloc_real means "malloc" in glibc,But what get_heap_end is.
I can not find get_heap_end in glibc.
Need help,Thanks

This is not an implementation bug, but an undisclosed design assumption. The code assumes that the type information from the code matches the run time types (pointer to type X always pointing to X or derived type). As such, the instrumented code is still vulnerable to buffer overflows triggered by type confusion or use-after-free bugs.

Example:

void foo(myStruct* ptr)
{
ptr->myField = X;
}

Here is SafePtr will assume that the access is correct, since myField is within the size of myStruct, when in fact ptr might be pointing to anything due to a type confusion or a use-after-free bug.

AddressSanitizer shares this limitation, but it is explicitely designed as a debug tool with no guarantees.

The byval attributes are uninstrumented (given fake upper bounds), but in reality the programmer can take the address of such argument and pass it along as any other pointer. At the IR level this looks as passing the "fake" pointer (with no bounds information) to the callee. This pattern is actually hit in either SPEC2006 or Chrome. There is also no need to use fake bounds information, since the actual size is already known at compile time.

As title says, people should not have to read through every line of the code to know about such limitations. Especially since the paper talks so much about the importance of handling arrays well, yet never mentions this limitation.

The size is already computed to be in bytes and not bits, yet it is divided by 8 again:

https://github.com/tudinfse/sgxbounds/blob/master/pass/sgxbounds.cpp#L1274
https://github.com/tudinfse/sgxbounds/blob/master/pass/sgxbounds.cpp#L229

The result is that certain memory accesses will be falsely assumed to be safe.