bareflank / boxy Goto Github PK

Add the following to the readme:

• Compilation instructions
• Usage instructions
• Installation instructions
• Emulation vs Virtualization
• Type 1 vs Type 2

Does boxy current support early booting?
Is there an API in Bareflank for send IPI interrupt?

We need a virtual clock. The Linux kernel needs support for a reliable clock source which it doesn't get from the APIC deadline timer. Providing a reliable clock source provides Linux with what it needs to enter NO_HZ mode. This task includes:

• Support for a vclock hypercall interface
• add a Linux clock source
• add a Linux clock event device
• add support for suspend/resume (as the TSC is reset on the host)

Hello,

While testing out the Bareflank capabilities for possible use in a project, I wanted to compile up Boxy on my Debian 9 (x86_64) system and while it seems that most things were compiling, I just ran into some errors:

==================================
Scanning dependencies of target boxy_domain
[ 4%] Building CXX object src/domain/CMakeFiles/boxy_domain.dir/domain.cpp.o
[ 8%] Linking CXX static library libboxy_domain.a
Scanning dependencies of target boxy_hve
[ 17%] Building CXX object src/hve/CMakeFiles/boxy_hve.dir/arch/intel_x64/virt/vclock.cpp.o
[ 17%] Building CXX object src/hve/CMakeFiles/boxy_hve.dir/arch/intel_x64/emulation/cpuid.cpp.o
[ 26%] Building CXX object src/hve/CMakeFiles/boxy_hve.dir/arch/intel_x64/emulation/x2apic.cpp.o
[ 26%] Building CXX object src/hve/CMakeFiles/boxy_hve.dir/arch/intel_x64/emulation/mtrr.cpp.o
/home/lonnie/Cloud/Type-2/boxy/bfvmm/src/hve/arch/intel_x64/virt/vclock.cpp:319:23: error: 'tsc' is not a class, namespace, or enumeration
auto tsc = ::x64::tsc::get();
^
/home/lonnie/Cloud/Type-2/boxy/bfvmm/src/hve/arch/intel_x64/virt/vclock.cpp:319:10: note: 'tsc' declared here
auto tsc = ::x64::tsc::get();
^
/home/lonnie/Cloud/Type-2/boxy/bfvmm/src/hve/arch/intel_x64/virt/vclock.cpp:340:23: error: 'tsc' is not a class, namespace, or enumeration
auto tsc = ::x64::tsc::get();
^
/home/lonnie/Cloud/Type-2/boxy/bfvmm/src/hve/arch/intel_x64/virt/vclock.cpp:340:10: note: 'tsc' declared here
auto tsc = ::x64::tsc::get();
^
/home/lonnie/Cloud/Type-2/boxy/bfvmm/src/hve/arch/intel_x64/virt/vclock.cpp:374:27: error: 'tsc' is not a class, namespace, or enumeration
if (auto tsc = ::x64::tsc::get(); tsc < next_event) {
^
/home/lonnie/Cloud/Type-2/boxy/bfvmm/src/hve/arch/intel_x64/virt/vclock.cpp:374:14: note: 'tsc' declared here
if (auto tsc = ::x64::tsc::get(); tsc < next_event) {
^
/home/lonnie/Cloud/Type-2/boxy/bfvmm/src/hve/arch/intel_x64/virt/vclock.cpp:408:35: error: no member named 'tsc' in namespace 'x64'
m_next_event_tsc = ::x64::tsc::get() + vcpu->rbx();
~~~~~~~^
/home/lonnie/Cloud/Type-2/boxy/bfvmm/src/hve/arch/intel_x64/virt/vclock.cpp:572:27: error: 'tsc' is not a class, namespace, or enumeration
if (auto tsc = ::x64::tsc::get(); tsc < m_next_event_tsc) {
^
/home/lonnie/Cloud/Type-2/boxy/bfvmm/src/hve/arch/intel_x64/virt/vclock.cpp:572:14: note: 'tsc' declared here
if (auto tsc = ::x64::tsc::get(); tsc < m_next_event_tsc) {
^
/home/lonnie/Cloud/Type-2/boxy/bfvmm/src/hve/arch/intel_x64/virt/vclock.cpp:610:9: error: no matching constructor for initialization of
'const vcpu_delegate_t &' (aka 'const delegate<void (bfobject *)> &')
{&vclock_handler::resume_delegate, this}
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/home/lonnie/Cloud/Type-2/boxy/build/prefixes/x86_64-vmm-elf/include/bfdelegate.h:303:5: note: candidate template ignored: could not match 'bfobject *' against
'bfvmm::intel_x64::vcpu *'
delegate(Ret(C::*memfn)(Args...), C *obj)
^
/home/lonnie/Cloud/Type-2/boxy/build/prefixes/x86_64-vmm-elf/include/bfdelegate.h:343:5: note: candidate template ignored: could not match
'void (bfobject *) const' against 'void (bfvmm::intel_x64::vcpu *)'
delegate(Ret(C::*memfn)(Args...) const, C *obj)
^
/home/lonnie/Cloud/Type-2/boxy/build/prefixes/x86_64-vmm-elf/include/bfdelegate.h:380:14: note: candidate template ignored: could not match
'void (bfobject *) const' against 'void (bfvmm::intel_x64::vcpu *)'
delegate(Ret(C::*memfn)(Args...) const, const C *obj)
^
/home/lonnie/Cloud/Type-2/boxy/build/prefixes/x86_64-vmm-elf/include/bfdelegate.h:268:5: note: candidate constructor template not viable: requires single
argument 'fn', but 2 arguments were provided
delegate(F fn)
^
/home/lonnie/Cloud/Type-2/boxy/build/prefixes/x86_64-vmm-elf/include/bfdelegate.h:234:5: note: candidate constructor not viable: requires single argument 'fn',
but 2 arguments were provided
delegate(Ret(*fn)(Args...))
^
/home/lonnie/Cloud/Type-2/boxy/build/prefixes/x86_64-vmm-elf/include/bfdelegate.h:396:5: note: candidate constructor not viable: requires single argument
'other', but 2 arguments were provided
delegate(const delegate &other) :
^
/home/lonnie/Cloud/Type-2/boxy/build/prefixes/x86_64-vmm-elf/include/bfdelegate.h:405:5: note: candidate constructor not viable: requires single argument
'other', but 2 arguments were provided
delegate(delegate &&other) :
^
/home/lonnie/Cloud/Type-2/boxy/build/prefixes/x86_64-vmm-elf/include/bfdelegate.h:209:5: note: candidate constructor not viable: requires 0 arguments, but 2
were provided
delegate() : m_call{nullptr}, m_vtbl{nullptr}
^
/home/lonnie/Cloud/Type-2/boxy/build/prefixes/x86_64-vmm-elf/include/bfvmm/hve/arch/intel_x64/vcpu.h:143:61: note: passing argument to parameter 'd' here
VIRTUAL void add_resume_delegate(const vcpu_delegate_t &d) noexcept
^
/home/lonnie/Cloud/Type-2/boxy/bfvmm/src/hve/arch/intel_x64/emulation/x2apic.cpp:45:17: error: no member named 'is_host_vcpu' in namespace 'vcpuid'; did you
mean 'is_host_vm_vcpu'?
if (vcpuid::is_host_vcpu(vcpu->id())) {
~~~~~~~~^~~~~~~~~~~~
is_host_vm_vcpu
/home/lonnie/Cloud/Type-2/boxy/build/prefixes/x86_64-vmm-elf/include/bfvcpuid.h:60:27: note: 'is_host_vm_vcpu' declared here
constexpr inline bool is_host_vm_vcpu(type id)
^
6 errors generated.
make[5]: *** [src/hve/CMakeFiles/boxy_hve.dir/build.make:102: src/hve/CMakeFiles/boxy_hve.dir/arch/intel_x64/virt/vclock.cpp.o] Error 1
make[5]: *** Waiting for unfinished jobs....
1 error generated.
make[5]: *** [src/hve/CMakeFiles/boxy_hve.dir/build.make:89: src/hve/CMakeFiles/boxy_hve.dir/arch/intel_x64/emulation/x2apic.cpp.o] Error 1
make[4]: *** [CMakeFiles/Makefile2:182: src/hve/CMakeFiles/boxy_hve.dir/all] Error 2
make[3]: *** [Makefile:118: all] Error 2
make[2]: *** [CMakeFiles/boxy_bfvmm_x86_64-vmm-elf.dir/build.make:113: boxy_bfvmm/x86_64-vmm-elf/stamp/boxy_bfvmm_x86_64-vmm-elf-build] Error 2
make[1]: *** [CMakeFiles/Makefile2:3046: CMakeFiles/boxy_bfvmm_x86_64-vmm-elf.dir/all] Error 2
make: *** [Makefile:84: all] Error 2
lonnie@debian:~/Cloud/Type-2/boxy/build$

==================================

Any ideas on this?

To be able to support virtual devices, we need a virtual IRQ system. This allows us to acquire a single interrupt within the guest kernel and use it to deliver whatever virtual interrupts we want. This task includes:

• Hooking up to the HYPERVISOR_CALLBACK_VECTOR within Linux
• Creating a vIRQ queue within the hypervisor so that virtual devices can interrupt the guest
• Provide a hypercall interface so that the guest OS can get the next vIRQ on the queue.

We need to provide a set of CPUID leaves that can be used by the guest to determine support for Boxy. Bareflank support can be seen by looking at 0x4BF00000. Boxy itself will need to implement the 0x40000000 like the other hypervisors as well as support to detect() function properly to place nice with nested virtualization.

Finally, we need to add detection code to the Linux kernel just for Bareflank, and not Boxy. The Bareflank code should scan all of 0x40000000 and if it gets an answer, it should fail detection to ensure downstream projects can coexist.

We need to add steps in our build system to sign the drivers with something other than the test signature.

If the TSC info is missing, the Linux kernel will attempt to use the PIT instead of erroring out and telling the user that the TSC info is missing and that this hardware is not supported. A serial device should not be needed to get this information.

We need to sort out the details of this Epic. There are a lot of components that need to be grabbed from our test branches, reworked, and fully tested.

We need to research how to do this, determine what we want to do with it, and then work out the Epic and its associated tasks

When I attempt to compile boxy using cmake I get errors about it not recognizing the "add_config" command (which I wasn't able to find mention of on Google). If I comment out the relevant lines I get a different errors about "add_custom_target_info" which I also can't find documented anywhere. Is this project using some non-standard version of cmake or something?

jonathan:~/git/boxy$ cmake --version
cmake version 3.13.4

CMake suite maintained and supported by Kitware (kitware.com/cmake).
jonathan:~/git/boxy$ cmake .
-- The C compiler identification is GNU 8.3.0
-- The CXX compiler identification is GNU 8.3.0
-- Check for working C compiler: /usr/bin/cc
-- Check for working C compiler: /usr/bin/cc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Detecting C compile features
-- Detecting C compile features - done
-- Check for working CXX compiler: /usr/bin/c++
-- Check for working CXX compiler: /usr/bin/c++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Detecting CXX compile features
-- Detecting CXX compile features - done
CMake Error at scripts/cmake/config/default.cmake:94 (add_config):
  Unknown CMake command "add_config".
Call Stack (most recent call first):
  CMakeLists.txt:26 (include)


CMake Warning (dev) in CMakeLists.txt:
  No cmake_minimum_required command is present.  A line of code such as

    cmake_minimum_required(VERSION 3.13)

  should be added at the top of the file.  The version specified may be lower
  if you wish to support older CMake versions for this project.  For more
  information run "cmake --help-policy CMP0000".
This warning is for project developers.  Use -Wno-dev to suppress it.

-- Configuring incomplete, errors occurred!
See also "/home/jonathan/git/boxy/CMakeFiles/CMakeOutput.log".

We need the ability to boot an ELF file using the new version of the ELF loader when it is ready. This is needed for a couple of reasons:

• We want to be able to execute C++ applications directly as a VM for integration, system and fuzz testing. This will need a simple 32-bit -> 64-bit converter because we do not plan on providing a 64-bit environment.
• With ELF loader support, we will be able to properly enforce EPT protections on the ELF file. If the guest is attacked, it will not be able to change the permissions of memory, even if it has control of CR3 inside the guest. This will also enable the ability to support shared pages and copy-on-write. Since a focus on the project is large numbers of VMs, this is needed
• With ELF loader support, we will also be able to load the kernel without the decompression phase.