mmu: fix a race in fast sigsegv code.

Fast sigsegv code detects COW pages by checking COW bit on write page
fault, but if page was COWed after the fault but before the check COW
bit will not be present. Check pte write permission too to avoid false
positives. If the race happens page will be writable.

Reviewed-by: Nadav Har'El <nyh@cloudius-systems.com>
Signed-off-by: Gleb Natapov <gleb@cloudius-systems.com>
Signed-off-by: Pekka Enberg <penberg@cloudius-systems.com>
mmu: remove unneeded code from cleanup_intermediate_pages

sub_page() is the same as default implementation.

Signed-off-by: Gleb Natapov <gleb@cloudius-systems.com>
Signed-off-by: Pekka Enberg <penberg@cloudius-systems.com>
elf: Run init functions only after loading object hierarchy

Amnon discovered a bug in our dynamic linker. The bug happens when we load
an object A.so which needs (DT_NEED) a second object B.so, and both have
some identical functions and variables (e.g., using the same C++ header files
with inline functions) and B.so has init functions (e.g., static
constructor). B.so's init function is run first, but the function it uses
belong to A.so, because A.so first on the search list (this is how it should
be, and I verified it is what happens on Linux as well).

In our existing code, when the needed library B.so's init functions are
run, A.so is not yet fully prepared (relocated, global variables resolved,
etc.) so B's use of A's function caused crashes when unrelocated PLT
entries or unresolved global variables get used.

To fix this, we need to split the loading of a hierarchy of objects into
two phases: First, we load the object, its needed objects, their needed
objects, etc., and keep a list of what we loaded. All this without running
any init function yet. After all these objects are fully loaded, their
symbols relocated and resolved as needed, do we finally run the init
functions of all the objects loaded in the first phase. We, of course,
run the init functions in reverse order, so the deepest library's init
functions is run first.

Signed-off-by: Nadav Har'El <nyh@cloudius-systems.com>
Signed-off-by: Pekka Enberg <penberg@cloudius-systems.com>
dlfcn: implement dlclose()

Outline of the implementation:

1. For each object, we need an unordered_set<std::shared_ptr<elf::object>>
   of other objects which were used to resolve its symbols.

2. Add std::enable_shared_from_this to class object which would allow to
   get a shared_ptr to it without any additional code.

3. In object::resolve_pltgot(), symbol(sym) returns a symbol_module
   which includes a pointer to the object containing the symbol.

4. For this object*, call object->shared_from_this() and add it to the
   unordered_set

5. Delete the shared_ptr in dlclose(), which will decrease the reference
   count of its dependent modules via the shared_ptrs.

I have tested it via the following method:

  Add a printf in remove_object

  extern int add(int,int);
  dlopen("add.so",RTLD_NOW); 	// resolves the add function
  int c = add(1,2); 	   	// the running .so now contains a reference to the add.so
  dlclose(add.so);		// this does not result in call to remove_object
  return;			// remove_object is first called for the .so and then for add.so

Fixes #150.

Reviewed-by: Nadav Har'El <nyh@cloudius-systems.com>
Signed-off-by: Jaspal Singh Dhillon <jaspal.iiith@gmail.com>
Signed-off-by: Pekka Enberg <penberg@cloudius-systems.com>
math: provide some more floating point symbols

Applications may require symbols like __isinf, __isnanl, etc. The standard
math.h header only provides macros. We currently have an implementation for
__isnan, but not for other important symbols that are being requested by the
application.

C++ have implementations of it, so there is no need to go for craft assemble.
I trully have no idea if our asm inline was more or less efficient than the C++
version, but I can't honestly imagine a program calling isinf in a loop 1
million times per sec.

For the record, it is an obvious possibility that the C++ implementation itself
could use those symbols, but I verified they don't. At least for x86. Example
code:

0000000000000040 <__isinfl>:
  40:   f2 0f 10 0d 00 00 00    movsd  0x0(%rip),%xmm1        # 48 <__isinfl+0x8>
  47:   00
  48:   31 c0                   xor    %eax,%eax
  4a:   55                      push   %rbp
  4b:   66 0f 54 c1             andpd  %xmm1,%xmm0
  4f:   48 89 e5                mov    %rsp,%rbp
  52:   5d                      pop    %rbp
  53:   66 0f 2e 05 00 00 00    ucomisd 0x0(%rip),%xmm0        # 5b <__isinfl+0x1b>
  5a:   00
  5b:   0f 97 c0                seta   %al
  5e:   c3                      retq

Signed-off-by: Glauber Costa <glommer@cloudius-systems.com>
CC: Claudio Fontana <claudio.fontana@huawei.com>
Signed-off-by: Pekka Enberg <penberg@cloudius-systems.com>