Is VMM-Isolation meaning vmm cannot be interfered?

[mor619dx]

Hello,

I've seen that VMM-Isolation is on the complete notes of this project but i'm not sure I understood what it means.

Does it means that the VMM is self protected? meaning that if i'm installing it on windows system no other code can interfer with the hypervisor? (etc take it off, writing to it's memory - DMA, editing the VMCS and more..)

Is such behavior even possible on Host-Only Hypervisors? (given the required support - VT-d for example)

Thank you for your help!

[rianquinn]

Welcome to the project!!!

A lot of host-only hypervisors that are used for research actually share resources with the host itself (for example, MoRE, SimpleVisor, and HyperPlatform all do this). So in our case, we simply mean that the VMM has it's own resources:

• Pages Tables
• GDT
• IDT
• Control Registers
• etc...

You can see the code here if you would like to take a quick look:
https://github.com/Bareflank/hypervisor/blob/master/bfvmm/src/vmcs/src/vmcs_intel_x64_vmm_state.cpp

Now... that all being said, we do have plans to protect the hypervisor in the future in our ExtendedAPIs repo (which should get under way here in a couple of weeks). Since we want Bareflank to provide the bare minimum scaffolding, we didn't want this code in the main repo so that it was optional. That task will include setting up both EPT and VT-d. We also have some fun tasks in the future like adding MPX support, better ALSR support, and better integration of the GSL.

Thoughts?

[mor619dx]

Hmm I've got reference from another projects to this one and I haven't had the time to actually go through the code and see how this projects goes.

I'm working on a startup group that is currently looking for creating a hypervisor with a support of our own use for it, so far this project seems like the best open source code for our needs although it lacks a lot of our needed features.

If our team will decide to use this project as our main hypervisor we will be sure to contribute our development and our features to this project to advance it and support the community.

[brendank310]

If you can elaborate on some of your required features, we can try to work them into the roadmap of the project and collaborate on how to best incorporate them.

[mor619dx]

Sorry for the delay.

We are working on an endpoint security software that uses virtuallization (a hypervisor) with combination with a few more technologies to enhance it.

In the long run we will need a pretty big number of features but our most basic needs are Split TLB easy to use library and self defense (that supports VT-d against DMA) - not only to the hypervisor itself but for some pages of memory accross the system as well.

Also performance is very critical for us so we need to take that for consideration.

We are currently 3 guys which 2 of us will work on the part of the hypervisor.

[rianquinn]

Nice. Our company is the original author (specifically @ranok) of the MoRE hypervisor so we are very familiar with TLB Splitting. We should be providing an EPT / VT-d RFC to start to mull over what the APIs will end up looking like in the Extended APIs repo. One of our goals in the long run was to port MoRE to Bareflank to demonstrate how it works, and to verify that the APIs work. Once the RFC comes out, please chime in so that we can ensure that your needs are meet.

[rianquinn]

@mor619dx Any issues with me closing this ticket? We have a Gitter account now were we can continue this conversation if you would like. If you do choose Bareflank, feel free to add feature requests to this issue tracker so that we can start prioritizing what goes into Bareflank over the next year.

Thanks again for your interest, and I hope we can work as team going forward.

[mor619dx]

Sure, We did choose to use Bareflank and soon we will start developing our needed modules.

The most needed feature is EPT, is this feature is in the planning for the nearby future or it's planned for next year / next version?

Either way since this feature is very basic for us so we might develop it ourselfs and RFC in the extended API project to make sure it's acceptable.

[rianquinn]

Woot

EPT is planned to be completed roughly around November (it's literally the first thing I'm working on once version 1.1 is done). Our goal is to get a guest (using a soon to be created Hyperkernel repo) up and running before the end of the year, and we will need EPT and some others to do that. Unless you beat me to it, I'll start an RFC on the EPT APIs where we can discuss what APIs we are going to need / want to use. FYI... RFCs for that repo will likely still occur in the hypervisor repo so we can keep things in one place.

Also... the #defines in intrinsics.h are pretty nasty, and Connor and I are working around the clock to clean them up ASAP so that we can reach some API stability. The RFC is here:

#241

Short story is, MSRs, VMCS fields, CPUID, the control registers and RFLAGS will all be a lot easier to use, but there will be a pretty massive code change in the VMM to support this. The big goal for version 1.1 is to reach a stable API so changes don't occur in the future, and we hope to have this version done in the next couple of weeks. I added a project page for version 1.1 so that we can track progress:

https://github.com/Bareflank/hypervisor/projects/1

As always PRs are always welcome, and if you want to add anything to the various different repos, feel free to toss a feature request / RFC into the issue tracker.