[gentoo-soc] Weekly Progress: Porting relibc

[Ahmed Soliman]

Hello,

This is the weekly progress report,

Last week I was trying to implement dlopen, dlclose, and dlsym, and
they worked as I expected for most of the cases, however there seemed
to be a complicated bug that only appeared in complex projects. That
bug appears in the form of memory corruptions at random places. The
problem here is that rust should in theory guarantee that this would
never happen unless you are doing unsafe code, even more so, the place
where I could observe this bug was safe code.

Specifically that was the snipped that puzzled me:

let mut data = Vec::new(); let mut file = File::open(&path_c,
flags).map_err(/*irrelevant*/)?; file.read_to_end(&mut
data).map_err(/*irrelevant*/)?; println!("load_recursive: name: {}
\"{}\"", (name).as_ptr() as usize, name); file.read_to_end(&mut
data).map_err(/*irrelevant*/); println!("load_recursive: name: {}
\"{}\"", (name).as_ptr() as usize, name);

and the output looked something like that
load_recursive: name: 93869686340272
"/home/oddcoder/sources/gcc/build/./gcc/liblto_plugin.so"
load_recursive: name: 93869686340272 "�o �o�o"

that code above is part of dlopen subroutine invocation.

At this stage I got stoned for little while with absolutely no idea
what to do, then I tried to write my own program that is statically
linked against that toy binary so I can observe what really happens.

so I did that with this toy program
//x86_64-lfs-linux-relibc-gcc code1.c -o code1 -llto_plugin
#include <stdio.h>
#include <unistd.h>
int main() {
        printf("hello world\n");
}
And it worked without crashing or anything so at this point I knew
that the problem is not with dynamic linking  at all.

So I created attempt 2
//x86_64-lfs-linux-relibc-gcc crasher.c -o crasher
#include <dlfcn.h>
int main() {
        void *lib1 =
dlopen("/home/oddcoder/sources/gcc/build/./gcc/liblto_plugin.so", 0);
        printf("Hello world\n");
}

And this program did segfault at stdlib::exit in a way that makes me
believe that is memory corruption,
The thing is the difference between dlopen and code base used by ld.so
is basically nothing, in fact it is the exact same code.
The only difference is that dlopen is usually called after libc.so is loaded.

My mentor (Luca Barbato) suggested using Rust GlobalAlloc to trace
memory allocations and see where the corruption is happening. Although
I understood the general idea, I still didn't know how to use it.
However, I found it used in relibc, not to trace memory allocation but
to implement relibc's custom memory allocator. So I thought maybe the
issue is there.

Under the hood for linux, Relibc is using dlmalloc with mmap disabled.
which means that all the memory allocations are done via brk()
syscall.

That made me believe that perhaps this is the root cause of the issue.
I also Learned that there is a global data structure used to do
bookkeeping and maintain a list of free memory chunks, I assumed that
if 2 instances of dlmalloc are running on the same heap, they would
probably corrupt it.

So to verify my assumption, I disabled normal malloc, and used mspaces
in dlmalloc which is basically a way for sharing the book keeping data
structure.

After being half implemented. (ld.so has it's own bookkeeping
structure which is isolated from relibc) the crasher no longer crashes
for some reason. But still full implementation would share the
bookkeeping structure between ld.so and relibc.
(note that the issue was that the memory was shared but each of them
maintaining different list of free/used chunk on the same memory,
however what would be ideal is that they would share the memory and
the list of used/freed memory)

I tried it on the real gdb code base and unfortunately it crashed but
due to completely different reasons (early crash). I did in fact skip
multiple details, I was inserting printlns everywhere and hacking
through the code trying to just get it working. There were things (for
example : mmap ) disabled in dlmalloc but was required for
for mspaces to work.

Now that I know that the basic idea worked for the memory corruption
proof of concept, I would just git reset --hard and try to implement
the fix as clean as possible.

What slightly worries me is that I could be totally unlucky and the
crash in gcc and segfault in the POC I created end up being completely
different bugs, and I will have to restart wondering what is causing
memory corruptions.


Thanks.
Ahmed.