x64: Remove VMware hypervisor probing

This removes the VMware hypervisor probing introduced in commit 7cb1ddf
("Hypervisor API: VMware support") because people are reporting that it
causes boot issues on some Amazon EC2 instance types.

Reported-by: Asias He <asias@cloudius-systems.com>
Signed-off-by: Pekka Enberg <penberg@cloudius-systems.com>
Merge branch 'stable/v0.15'
x64: Use DMI BIOS vendor for detecting Xen hypervisor

If we fail to detect Xen clocksource, fallback to checking firmware
vendor from DMI tables.

Signed-off-by: Pekka Enberg <penberg@cloudius-systems.com>
Merge branch 'stable/v0.15'
loader.cc: Fix if_name() related use after free

With "conf-debug_memory=1", I am seeing the following splash when
building a new image:

  /home/penberg/osv/scripts/mkzfs.py -o bare.img -d bare.img.d -m bootfs.manifest
  OSv v0.15
  eth0: 192.168.122.15
  page fault outside application, addr: 0xffffb0000519a000
  [registers]
  RIP: 0x000000000043ba75 <strlen+37>
  RFL: 0x0000000000010246  CS:  0x0000000000000008  SS:  0x0000000000000010
  RAX: 0xffffb0000519a018  RBX: 0x0000000000618846  RCX: 0x9b97bcffafb6a0a9  RDX: 0x030700ff0f000001
  RSI: 0x8080808080808080  RDI: 0xffffb0000519a018  RBP: 0x00002000001ffc10  R8:  0xfefefefefefefeff
  R9:  0x8080808080808080  R10: 0x0007fffffffff000  R11: 0xffff800000000000  R12: 0x0000000000000001
  R13: 0x8080808080808080  R14: 0x0007fffffffff000  R15: 0xffff800000000000  RSP: 0x00002000001ffc10
  Aborted

  [backtrace]
  0x000000000032c42f <???+3327023>
  0x000000000032d563 <mmu::vm_fault(unsigned long, exception_frame*)+147>
  0x0000000000390f39 <page_fault+105>
  0x000000000038fe26 <???+3735078>
  0x000000000044d1aa <setenv+122>
  0x0000000000212d2b <do_main_thread(void*)+2987>
  0x000000000043f5a5 <???+4453797>
  0x00000000003ec7b7 <thread_main_c+39>
  0x0000000000390da5 <???+3739045>
  0x2221201f1e1d1bff <???+505224191>
  0x00000000003ecd8f <???+4115855>
  0x48ec834853fc8948 <???+1409059144>

Looking at the code, we take a pointer to a string that's returned from
osv::if_ip(). However, as soon as we exit the scope, the string is
destroyed and memory is recycled.

The bug was introduced in commit a296f8b ("loader: Adding OSV_IP
environment variable").

Reviewed-by: Nadav Har'El <nyh@cloudius-systems.com>
Signed-off-by: Pekka Enberg <penberg@cloudius-systems.com>
Merge branch 'stable/v0.15'
libc: use getenv() from musl

While chasing other bugs, I noticed we have our own copy of getenv.c
just so we can add a secure_getenv(). Better just add it in a separate
file, and use the unmodified getenv.c from musl.

Signed-off-by: Nadav Har'El <nyh@cloudius-systems.com>
Signed-off-by: Pekka Enberg <penberg@cloudius-systems.com>
Revert "scripts: Make release images include default configuration"

This reverts commit 1fa749165e4521988305910b3a771927f71520a0. We don't
want to automatically pull the CLI, for example, for Redis appliances.
Switch back to requiring release images to explicitly specify their
dependencies.

Signed-off-by: Pekka Enberg <penberg@cloudius-systems.com>
Merge branch 'stable/v0.15'
debugging malloc: fix realloc()

In about 10% of the boots with the debugging allocator enabled
(conf-debug_memory=1), we fail on setenv() which frees some memory
and thinks it sees an overflow. But this is not a real setenv() bug,
but just a false alarm - a bug in the debugging allocator. This patch
fixes this bug:

When debugging malloc is enabled (conf-debug_memory=1), most malloc()
calls are done with dbg::malloc(), but some allocations are still
performed by the standard allocator. This includes some very early
allocations (before the debugging allocator is enabled) and nested
allocations from within the debugging allocator. For this reason,
free() checks every address if it is in the debugging-allocator range
or the standard allocator range.

realloc() needs to do the same, of course, for the old pointer passed
to it. But realloc() called dbg::realloc() which then called "free()".
This unqualified "free()" ends up calling dbg::free() always, even
for addresses not allocated by the debugging allocator. It needs to
call ::free(), not free(), to ensure that each address is checked
separately on how to free it.

The bug was seen with setenv() because setenv() uses realloc() to
allocate the environment variable buffer, and because loader.cc
sets one environment variable *before* enabling the debugging allocator,
so it is originally allocated with the standard allocator - and later
realloc()ed with the debugging allocator enabled.

Fixes #549.

Signed-off-by: Nadav Har'El <nyh@cloudius-systems.com>
Signed-off-by: Pekka Enberg <penberg@cloudius-systems.com>
x64: fix format string in dump_registers()

rip and rflags are 64 bit so %lx should be used instead of %x.

Reviewed-by: Nadav Har'El <nyh@cloudius-systems.com>
Signed-off-by: Paweł Dziepak <pdziepak@quarnos.org>
Signed-off-by: Pekka Enberg <penberg@cloudius-systems.com>
memory: merge std_realloc() and dbg::realloc()

All that std_realloc() needs to handle debug allocations is
object_size() supporting them and that's what this patch adds. The logic
in dbg::realloc() and std_realloc() is basically the same so there is no
reason for the former to exist.

Also, since now object_size() handles memory allocated by debug
allocator malloc_usable_size() doesn't aborts anymore when given such
allocation.

Reviewed-by: Nadav Har'El <nyh@cloudius-systems.com>
Signed-off-by: Paweł Dziepak <pdziepak@quarnos.org>
Signed-off-by: Pekka Enberg <penberg@cloudius-systems.com>
fix buffer overflow in tls setup

The kernel ELF image contains only .tdata section, there is no .tbss and
the only information about it is in the differenct between PT_TLS file
and memory size. Therefore, it is incorrect to create full, ready to use
TLS template in place, i.e. by zeroing memory area directly following
the .tdata section, since it may overwrite something important (or be
overwritten by something else).

Reviewed-by: Nadav Har'El <nyh@cloudius-systems.com>
Signed-off-by: Paweł Dziepak <pdziepak@quarnos.org>
Signed-off-by: Pekka Enberg <penberg@cloudius-systems.com>
mmu: flush tlb after clearing PDE entry

CPU may have PDE cache, even if all PTEs are invalid, which need to be
flushed when PDE changes.

Signed-off-by: Gleb Natapov <gleb@cloudius-systems.com>
Signed-off-by: Avi Kivity <avi@cloudius-systems.com>
Add API for extension API
Modified module/httpserver/Makefile to separate build module/httpserver/api/plugin.cc
To load so module in global_server(Cannot build correctry)
To use dlopen(3)