setup.py: Add libssl.so installation

Needed by SSL module for Lua (LuaSec).

Signed-off-by: Or Cohen <orc@fewbytes.com>
Signed-off-by: Pekka Enberg <penberg@cloudius-systems.com>
Lua: Add LuaSec module

Will be used for SSL connections to the API.

Signed-off-by: Or Cohen <orc@fewbytes.com>
Signed-off-by: Pekka Enberg <penberg@cloudius-systems.com>
cli: Add support for HTTPS

* Added support for SSL in osv_api.lua
* Added a few context options related to SSL keys/certs
* Added program options to set SSL keys/certs

Signed-off-by: Or Cohen <orc@fewbytes.com>
Signed-off-by: Pekka Enberg <penberg@cloudius-systems.com>
Revert "Lua: Add LuaSec module"

This reverts commit 6066440cabe32523fedb1ed99286f86c864f1ce3.
Lua: Add LuaSec module

Will be used for SSL connections to the API.

LuaRocks manually looks for shared objects and other library files in
predefined locations. For some reason it ignores /usr/lib64 (where available),
so this contains a small workaround to address that specifically for LuaSec.

Signed-off-by: Or Cohen <orc@fewbytes.com>
Signed-off-by: Pekka Enberg <penberg@cloudius-systems.com>
mmap(): special treatment for MAP_STACK

Linux's mmap() API has a flag, MAP_STACK, which is a no-op on Linux, but
was added to the API in case "some architectures require special treatment
for stack allocations" (see mmap(2)). Unfortunately, OSv indeed has a
special requirement for stack memory: As explained in issue #143, we
currently do not support demand-paged stacks (i.e., accessing the stack
cannot cause a page fault), so the stack must be allocated pre-faulted
and pinned.

So if an application did us the courtesy of actually using MAP_STACK
when mmap'ing a stack, let's return the favor by mapping pre-faulted
memory which will actually work if used as a stack.

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