Merge pull request #111 from rianquinn/fix_stack_pointer_kernel_ooppss

Fix Fedora Kernel Panic

Author: rianquinn

CHANGELOG.md

@@ -0,0 +1,19 @@
+# Change Log
+
+## [1.0.0] - 2016-27-04
+### Added
+- Linux support
+- Custom C runtime library for constructor / destructor support and registering
+  exception handlers
+- Custom driver entry logic for loading the VMM
+- Custom ELF loader for loading the VMM modules
+- Userspace managament application (BFM) for starting / stopping the
+  hypervisor
+- Custom kernel-safe unwind library for adding exception support to the VMM
+- Basic VMM with support for Intel x86_64. The VMM places the Host OS into
+  a virtual machine and back out. Currently can be extended to provide
+  additional functionality
+- Custom build environment
+- Complete set of unit tests
+- Documentation
+- Scripts for setting up Unbuntu, Debian and Fedora build environments.

README.md

@@ -40,39 +40,39 @@ that the provided code works as expected.
 
 ## Motivation
 
-Most people think that hypervisors are meant to virtualize servers and 
-provide a means to run Windows on a Mac, but there is a whole field 
-of research were hypervisors are used without guest virtual 
-machines. Since a hypervisor is capable of controlling the host OS 
-running underneath it, (so called "ring -1"), hypervisors have been 
-used for introspection, reverse engineering, anti-virus, containerization, 
-diversity, and even architectural research like the 
-[MoRE](https://github.com/ainfosec/MoRE) hypervisor. All of these use 
-cases start the same way, by spending months standing up the hypervisor 
-itself before you can start working on your actual project. Existing open 
-source hypervisors are so focused on supporting virtual machines and 
-burdened with legacy support that they are painful to work with when 
-conducting less traditional hypervisor research. 
-
-Bareflank's goal is to provide the scaffolding needed to create any type of 
-hypervisor. To support this, Bareflank leverages C++ not only to provide 
-a clear method for extending the hypervisor via inheritance, but also to 
-provide access to the C++ STL to reduce the time it takes to prototype and 
-implement new technologies. For example, suppose your writing an 
+Most people think that hypervisors are meant to virtualize servers and
+provide a means to run Windows on a Mac, but there is a whole field
+of research were hypervisors are used without guest virtual
+machines. Since a hypervisor is capable of controlling the host OS
+running underneath it, (so called "ring -1"), hypervisors have been
+used for introspection, reverse engineering, anti-virus, containerization,
+diversity, and even architectural research like the
+[MoRE](https://github.com/ainfosec/MoRE) hypervisor. All of these use
+cases start the same way, by spending months standing up the hypervisor
+itself before you can start working on your actual project. Existing open
+source hypervisors are so focused on supporting virtual machines and
+burdened with legacy support that they are painful to work with when
+conducting less traditional hypervisor research.
+
+Bareflank's goal is to provide the scaffolding needed to create any type of
+hypervisor. To support this, Bareflank leverages C++ not only to provide
+a clear method for extending the hypervisor via inheritance, but also to
+provide access to the C++ STL to reduce the time it takes to prototype and
+implement new technologies. For example, suppose your writing an
 introspection hypervisor that needs to store the different system calls that
-are being made in a hash table for fast lookups. Doing this in an existing C 
-based hypervisor might require you to create your own hash table implementation. 
-This same implementation is trivial with the STL's existing data structures. 
-With Bareflank's design, you can focus on the goal of your project, and less 
-on implementing the foundation needed to support your project. 
+are being made in a hash table for fast lookups. Doing this in an existing C
+based hypervisor might require you to create your own hash table implementation.
+This same implementation is trivial with the STL's existing data structures.
+With Bareflank's design, you can focus on the goal of your project, and less
+on implementing the foundation needed to support your project.
 
-Bareflank will always maintain the "bare minimum" needed to stand up a 
+Bareflank will always maintain the "bare minimum" needed to stand up a
 hypervisor. Future repositories/projects will be created that extend
-the hypervisor to add additional API support for common research tasks (e.g. 
-VT-x APIs, LibVMI APIs, and even guest support APIs). Long term, it is our 
-hope that others will leverage Bareflank to create hypervisors 
-capable of competing with existing type 1 and type 2 open source hypervisors, 
-but Bareflank itself will remain focused on the bare minimum scaffolding. 
+the hypervisor to add additional API support for common research tasks (e.g.
+VT-x APIs, LibVMI APIs, and even guest support APIs). Long term, it is our
+hope that others will leverage Bareflank to create hypervisors
+capable of competing with existing type 1 and type 2 open source hypervisors,
+but Bareflank itself will remain focused on the bare minimum scaffolding.
 
 ## Website
 
@@ -142,18 +142,18 @@ functionality, we have provided a couple of examples:
 [Enable VPID](https://github.com/Bareflank/hypervisor_example_vpid) <br>
 [CPUID Count](https://github.com/Bareflank/hypervisor_example_cpuidcount)
 
-## Roadmap (updated 4-21-2016)
+## Roadmap (updated 4-27-2016)
 
 ### Version 1.0
 
-Target: April 2016
+Released: April 27, 2016
 
 * ~~ELF Loader~~
 * ~~Userspace Managment Application (bfm)~~
 * ~~Unwinder~~
 * ~~Initial C++ Environment~~
 * ~~Linux Driver Entry~~
-* Basic VMM
+* ~~Basic VMM~~
 * ~~Testing (Ubuntu, Debian, Fedora, CentOS)~~
 
 ### Version 1.1

TODO.md

@@ -19,14 +19,10 @@ Misc:
 - Modify the common.c code in the driver entry to handle memory protections
   properly. Specifically, we want to make sure that we are respecting the
   read/execute and read/write memory protections that are labeled by the
-  ELF program loader. This isn't useful until we break apart libc++.so such
-  that it's not marked r/w/x (likely to be solved with the new libc)
+  ELF program loader.
 - Add system beep code for additional debugging
 - Add support for the PCI debugger
 
-Version 1.0 TODO:
-- Need to have all of the VMCS checks unit tested
-
 Version 1.1 TODO:
 - Need to have a completely isolated exit handler. It should have it's own
   CR3, IDT, and GDT.
@@ -47,7 +43,7 @@ Version 1.2 TODO:
 - Multiple guest support running http://www.includeos.org/ or some other
   unikernel. Note that the actual guest support will likely be in a different
   repo, but Bareflank itself will need some changes to support this (for
-  example, some organizational changes to the vcpu to run a guest). 
+  example, some organizational changes to the vcpu to run a guest).
 - Hyperkernel support
 
 Known Issues:

bfdrivers/src/arch/linux/entry.c

@@ -7,6 +7,8 @@
 #include <linux/kallsyms.h>
 #include <linux/cpumask.h>
 #include <linux/sched.h>
+#include <linux/notifier.h>
+#include <linux/reboot.h>
 
 #include <debug.h>
 #include <common.h>
@@ -35,13 +37,19 @@ struct mm_struct *g_mmu_context = NULL;
 static int
 dev_open(struct inode *inode, struct file *file)
 {
+    (void) inode;
+    (void) file;
+
     DEBUG("dev_open succeeded\n");
     return 0;
 }
 
 static int
 dev_release(struct inode *inode, struct file *file)
 {
+    (void) inode;
+    (void) file;
+
     DEBUG("dev_release succeeded\n");
     return 0;
 }
@@ -274,13 +282,21 @@ ioctl_vmm_status(int64_t *status)
     return BF_IOCTL_SUCCESS;
 }
 
+static void
+helper_fini(void)
+{
+    set_cpu_affinity(current->pid, cpumask_of(0));
+    common_fini();
+}
+
 static long
 dev_unlocked_ioctl(struct file *file,
                    unsigned int cmd,
                    unsigned long arg)
 {
-    const struct cpumask *cpu0 = cpumask_of(0);
-    set_cpu_affinity(current->pid, cpu0);
+    (void) file;
+
+    set_cpu_affinity(current->pid, cpumask_of(0));
 
     switch (cmd)
     {
@@ -328,14 +344,34 @@ static struct miscdevice bareflank_dev =
 };
 
 /* ========================================================================== */
-/* Entry                                                                      */
+/* Entry / Exit                                                               */
 /* ========================================================================== */
 
+int
+dev_reboot(struct notifier_block *nb,
+           unsigned long code, void *unused)
+{
+    (void) nb;
+    (void) code;
+    (void) unused;
+
+    helper_fini();
+
+    return NOTIFY_DONE;
+}
+
+static struct notifier_block bareflank_notifier_block =
+{
+    .notifier_call = dev_reboot
+};
+
 int
 dev_init(void)
 {
     int ret;
 
+    register_reboot_notifier(&bareflank_notifier_block);
+
     set_cpu_affinity = (set_affinity_fn)kallsyms_lookup_name("sched_setaffinity");
     if (set_cpu_affinity == NULL)
     {
@@ -362,8 +398,10 @@ dev_init(void)
 void
 dev_exit(void)
 {
-    common_fini();
+    helper_fini();
+
     misc_deregister(&bareflank_dev);
+    unregister_reboot_notifier(&bareflank_notifier_block);
 
     DEBUG("dev_exit succeeded\n");
     return;

include/mainpage.h

@@ -5,6 +5,7 @@
 ///     -# @ref unit_tests
 ///     -# @ref extending_bareflank
 ///     -# @ref vmm_reference
+///     -# @ref serial
 ///
 /// @section description Description
 ///
@@ -288,3 +289,42 @@
 /// @ref debug_ring <br>
 /// @ref serial_port_intel_x64 <br>
 ///
+/// @section serial Serial Setup
+///
+/// With VMWare, Bareflank will use serial0 to output bfxxx / std::cout /
+/// std::cerr by default. On some VMWare systems, the printer uses serial0,
+/// so you might have to remove (disabling is not enough) the printer prior
+/// to adding the serial device. Worst case, you can modify the .vmx file
+/// manually to setup serial0.
+///
+/// On physical hardware however, you might have to define the serial port
+/// during compilation to something other than the default (or if you
+/// want to use a different VMWare serial port). To tell Bareflank to use
+/// a different port, you need to define the default port prior to
+/// compiling Bareflank.
+///
+/// export CROSS_CXXFLAGS="-DDEFAULT_COM_PORT=0x<port #>"
+///
+/// By default this is set to "COM1_PORT" or "0x3f8". You can set this to
+/// any of the following:
+/// - COM1_PORT
+/// - COM2_PORT
+/// - COM3_PORT
+/// - COM4_PORT
+/// - 0x<port #>
+///
+/// On some Intel systems with PCI serial devices the port numbers are:
+/// - 0xe000
+/// - 0xe010
+///
+/// You can use the above method to define all of the parameters for serial
+/// as well. The default values are listed below, and you can change them
+/// to anything you wish:
+/// - DEFAULT_COM_PORT=COM1_PORT
+/// - DEFAULT_BAUD_RATE=baud_rate_115200
+/// - DEFAULT_DATA_BITS=char_length_8
+/// - DEFAULT_STOP_BITS=stop_bits_1
+/// - DEFAULT_PARITY_BITS=parity_none
+///
+/// For more information, please see serial_port_intel_x64.h
+///

tools/scripts/setup-fedora.sh

@@ -59,6 +59,7 @@ case $(lsb_release -sr) in
     sudo dnf install -y libstdc++-static
     sudo dnf install -y kernel-devel
     sudo dnf install -y kernel-headers
+    sudo dnf update -y kernel
 
     ;;
 
@@ -73,3 +74,9 @@ esac
 # ------------------------------------------------------------------------------
 
 ./tools/scripts/create-cross-compiler.sh
+
+# ------------------------------------------------------------------------------
+# Reboot
+# ------------------------------------------------------------------------------
+
+echo "WARNING: A reboot is required before you can build the hypervisor!!!!!"

tools/scripts/setup-ubuntu.sh

@@ -37,6 +37,9 @@ fi
 # ------------------------------------------------------------------------------
 
 case $(lsb_release -sr) in
+16.04)
+    ;&
+
 15.10)
     ;&