Detect abuse of dlopen and dlsym

[Qcloud1223]

A compromise I made during I writing this project is that a non-system dynamic linker is nearly impossible to correctly load glibc, so that I turn to dlopen and dlsym to resolve glibc symbols.

This could cause questions, for example:

// MapLibrary,c
void *MapLibrary(const char *libpath)
{
    LinkMap *l = malloc(sizeof(LinkMap));
    return (l->fakeHandle = dlopen(libpath, RTLD_LAZY));
}

// RelocLibrary.c
void RelocLibrary(LinkMap *lib, int mode)
{
    return;
}

In a word, one may call dlopen on every shared object and get away with the autograder.

I fully believe the students who are working on this project, and will still keep my grading policies. However, I do want to fix the imperfectness.

Possible solutions are as follows:

1. Using hash-based method to keep 'fake load' code segment 'untainted'. The problem is that I want to restrict the way students write the code.
2. Interpose dlopen. Using a wrapper to count how many times dlopen and dlsym are called, and print it to stderr. I can make sure how many times these functions need to be called. This seems alright, but needs to make sure Makefile is not modified.

[Qcloud1223]

Thanks to @SoullAngle, he pointed out that one could easily bypass test 6 by printf when using lazy relocation.

Currently, I think this could be fixed by interposing printf as well, but this is not the perfect way, for ultimately printf is write to stdout, and syscalls cannot be interposed. Plus, I highly doubt that interposing printf will crash gdb.

To make things broader, it seems that every test can be bypassed by simply printf, depending on the library loaded. Should I work for ultimate automatically evaluation, or allow the imperfectness, manually inspecting the code?

[Qcloud1223]

Addressed in PR #14