Thank you, so it's a pleasure to be here and having the chance to talk about our work
on virtualization system security.
So today we will explore how virtualization techniques can enhance the security of the Linux
kernel.
Specifically, I will provide an overview of the Blurock security architecture which leverages
virtualization extensions to enhance the security of the subsystems of the Linux kernel.
So the problem that we are trying to solve is the following.
So the Linux architecture currently faces, well, let's call it, interact challenges in
its security design.
Fundamentally, the OS distinguishes between the well less privileged user space and
the highly privileged kernel space.
So this design ensures that the kernel is all remains in control of user space applications.
In other words, the kernel is responsible for protecting and isolating user space applications.
At the same time, it is also the kernel who bears the responsibility of protecting itself
from unauthorized access.
And if we, for a moment, assume that the kernel has been compromised.
The question arises, who could actually protect the Linux kernel from unauthorized access?
And we believe that the answer lies in virtualization assisted security.
So the idea behind virtualization assisted security is as follows.
So it is about designing an architecture that alleviates the strict separation between the
Linux kernel and a VMM.
So we propose to empower the kernel to directly integrate virtualization extensions as inner-end
building blocks into their subsystem.
We consider virtualization extensions as not limited to VMMs, but rather as a hardware resource,
host capabilities can really greatly benefit the security of OS systems.
So by equipping the Linux subsystems with security primitives provided by the VMM, the VMM
evolves beyond its traditional role of basically implementing the virtual hardware interface
and becomes a resilient security support layer for virtual machines.
In short, through virtualization assisted security, we aim to strengthen the Linux kernel
against basically the defense of the Linux kernel against malicious actors even in the presence
of potential kernel vulnerabilities.
Now before we can dive deeper into the topic, I suggest to introduce a blur of security architecture.
This architecture encompasses several key components which would also allow us to follow
the presentation.
The first component is the security support layer.
So the architecture uses the Nova microhypervisor as its security support layer for VMMs.
It provides a hypercalling interface to supply VMs with fast capabilities and at the moment
it supports 64-bit Intel and RB8 applications CPUs.
So since the underlying concepts are fully hypervisor-nostic, they can be similarly applied
to also other implementations such as Linux KVM.
The next component of the architecture is the workload VM.
So it runs in enlightened or paramilitarized Linux kernel and combined with the underlying
security support layer, this VM or this component presents the primary focus of this presentation.
So this VM collaborates actively with the underlying security support layer and thus leverages
vast building blocks to enhance the security of the kernel subsystem.
So depending on the system's configuration the workload VM can also operate as the sole VM
on the system and does not necessarily require any additional VMs to assist its security.
The workload VM interacts with the underlying security support layer through hypercalls
and hypercalls are used here in this context to initialize and also to commit to a given security
policy.
But they are also used to verify whether a specific operations are permitted within a given context.
So, optionally the workload VM can generate high-level security events such as process
life cycle and container drift events and they are then sent through these on through
these circuit to an external monitor.
So these events provide insights for an external security monitor which can react to potential
threats.
Any policy violation triggers the security support layer to eject faults into the workload
VM and thus basically avoid an authorized operation.
The final component of this architecture is the control day in VM and this component is optional
and it won't be considered in the rest of the presentation.
It's still for the sake of completeness I would like to quickly introduce it.
So it receives the security events which were originated or generated by the workload
VM and it allows security experts to basically define and maintain OPA-based security policies
which can be then enforced through the underlying security support layer.
So this design basically decouples policy decision from policy enforcement points.
Now that we have covered the overall security architecture, I would like to start talking
about specific vast primitives that our system implements.
So the Linux currently integrity primitive is one of the main primitives and it empowers
the workload VM to basically protect its kernel code in read-only sections against unauthorized
modification.
So even if a attacker is gained kernel privileges, this primitive prevents them from modifying
protected code and from, for example, from injecting code into the kernel in an unauthorized
way.
The selective data structure in pointer protection primitive is designed to protect the
integrity of sensitive or critical data structures and well their pointers.
It binds pointers to sensitive data or of sensitive data structures to unique and immutable
contexts and verifies their integrity and designated verification points.
Now the security support layer implements also further primitives including control register
value blocking of a simple policy protection driver signature enforcement and many more.
And all of them can be leveraged by the workload VM to support or to protect its subsystems.
But since we have timing constraints, I will only cover the first primitive which is the
Linux kernel integrity protecting protection.
Now as such I suggest to take a closer look at this primitive.
So the VM or as I mentioned before the workload VM leverages hypercalls to communicate
with the underlying security support layer.
In this context the VM employees hypercalls to register memory regions within the security
support layer.
So this concept applies not only to static kernel code in data segments but also to dynamically
loadable code in data for example this includes kernel modules and of course ppf programs.
So by using this vast primitive the VM enhances the kernel memory management capabilities.
In fact it combines the kernel memory management with the system's second level address
translation capabilities to grant access permissions exclusively to memory regions which
happened previously registered.
Now in this way the system becomes able to identify or intercept for example unauthorized
supervised execution attempts and this way effectively to award in for example injections
of unknown or malicious code into the kernel.
And as you can see here on the slide in this example we have an unauthorized execution
attempt of the unknown memory region which is marked as red and because it was not registered
beforehand it can be intercepted and basically awarded.
So all of this works because each registered memory region is categorized by memory
type and associated flex.
So the memory type is hypervisor and hardware independent and it is basically internally
hyperdefined memory permission format.
But the memory flex in particular transient and mutable describe additional properties
of the associated memory region which we should quickly look at.
So first the transient flag indicates whether a given memory region is static or dynamic.
So this flag determines if a previously registered memory region can be retrospectively removed
from the system.
And as you can see on the slide here the workload VM uses the integrity create hypercall
to first register a transient memory region which belongs to a kernel module.
Now at the later point in time when the kernel module gets unloaded the workload VM can unload
the VM.
Sorry can can unregister the previously registered memory or to release the memory.
Please note that any attempt to release non-transit memory will cause the security support
layer to inject the fault into the VM.
The mutable flag allows to update the type of the memory.
So the permissions of the registered memory regions.
And on this slide we see again that the workload VM uses creates or registers a memory region
which is first mutable and it has read write permissions.
At a later point in time the VM can use the integrity update hypercall to change the
permissions of the previously registered memory region.
So in this case the type is changed or the permissions are changed from read writes to read only.
Here again please note that the mutable flag allows updating only to more restrictive memory
types.
Subsequent updates cannot grant more permissions than we are initially assigned to the memory
region.
Now by using the presented memory model we become able to support basic operations.
So we can boot up the loans kernel we can load kernel modules and BPM programs.
However in reality the kernel is much more dynamic than that and heavily relies on runtime
patching to optimize performance and functionality.
So this means that without explicit support for patching the previously presented integrity
primitive will raise a false positive every time the system tries to patch itself.
And this is a problem.
Here some key patching facilities that are supported by the kernel just to provide
a small overview we have something like alternative instructions which replace instructions
with their most optimized version depending on the CPU.
We have jump labels which are used to toggle rarely use conditional code paths again by patching
kernel code.
Then we have set a key study calls which use jump labels underneath and we have also something
like trace points which allow to text probes to hooks in the kernel code for tracing purposes.
And while all of these patching facilities are very useful they can present significant
security risks.
So attackers can abuse these patching facilities to take over control over the Linux kernel.
So attackers can reuse patching related code or even modify patching related data structures
to basically to take over the system.
So this can lead to an authorized modification of the kernel code or even to disabling
particular security events in the system.
And all of that of course even though we have more and see if I'm Michigan's in place.
So at this point the question arises how or is it even possible to reliably distinguish
between legitimate and malicious patching activities?
Well generally to vortex targeting the patching facility we would need to first guarantee
that the patching facility is called only from a trusted benign context.
And second we need to maintain the integrity of the patching related data structures.
So the issue of hand is that even though we can address the first point through something
like CFI the second requirement will remain an open challenge.
And because of this we propose again virtualization is security to meet both requirements.
In this context we introduce the vault.
The vault is a well new security primitive which is designed to isolate subsystems in the Linux
kernel.
In a nutshell we provide an API to encapsulate and isolate sensitive code and data in dedicated
sections that belong to the vault.
So in this way we become able to logically partition the Linux kernel and shift entire subsystems
if needed and there are associated data structures into separate vaults.
So the goal here is to really restrict the kernel from directly accessing memory within
the vault.
So access to this memory should be controlled through a strictly governed transition
points into and out of the vault and any unauthorized attempt to to basically access
this memory should raise a violation.
So by implementing the vault our main goal is to effectively prevent attackers from
reusing protected code and from modifying sensitive data within the vault.
Now before we continue I suggest we quickly recap the concepts of second level address
translation.
And here typically a VMM uses a single set of slatables which translate gas physical
to machine or host physical memory.
So in other words a single set of slatables defines the gas view on its physical memory.
If we change the permissions of this global set of slatables which is by the way very
slow operation we will inevitably affect the global view of the memory as it is perceived
by all these computers in the system.
Now instead of using a single global view on the gas physical memory the Nova gas
spaces subsystem allows us to maintain and dynamically switch among different views.
So by switching the views we basically can can efficiently change permissions without having
to walk this global set of slatables.
And even even more important this doesn't require us to affect any other or the views
of any other VCUs.
So in all of this creates the basis that we need for implementing the vault.
So as we also know the hardware allows us to have only one memory view to be active at
a given time.
And at the same time we would like to configure multiple memory views to guard this joint
memory sections that belong to a vault.
And these destroyed sections cannot be accessible at the same time.
So what I'm trying to say is that we cannot simply associate one vault with a given
or with only one memory view instead we require two views to implement one vault.
So we dedicate one view which is the restricted kernel view to unify all memory restrictions
of the system and this becomes the default view in the system.
We use the second view to relax restrictions for a given memory region or for given memory
regions that belong to a vault.
Now to accomplish and vaults we would need to define n plus one memory views and by entering
a specific vault we basically relax the permissions of the memory region that belongs to
this particular vault while all other views would remain in their restricted state.
Now that we have established a technical concept behind the vault primitive I would like
to discuss how this works in practice.
And the following slides are going to be a little bit fun so please bear with me.
We have integrated the vault into the kernel to protect against attacks targeting the patching
and tracing facility.
So by using the vaults API we basically encapsulate the necessary code and data of the patching
and tracing facility and designated memory sections.
Additionally we clearly define the vault's entry and exit points and share this information
during early boot with the underlying security support layer.
Now to implement the security patching primitive that is compatible with the previously
previously introduced integrity primitive we define the following requirements.
First we consider the code outside of the vault is untrusted.
So our goal is to really prevent a potentially compromised kernel from reusing code gadgets
inside of the vault.
Second it is important that only the code that is inside of the vault has access to the
sensitive data structures inside of the vault.
So any unauthorized access to these data structures from the outside of the vault shall
be blocked.
And third and this applies to this example with patching the code within the vault should not
be able to directly patch the Linux kernel itself.
Instead it should instruct the security support layer through hypercalls to patch the respective
code regions on behalf of the subsystems.
So these patching requests are considered trusted because they originate from a secure trusted
or verified location in the vault and they hold data that is also a vault protected.
Now to isolate the subsystem in the vault we integrate or leverage Nova gas spaces and
specifically we create two additional views on the gas physical memory.
So the first view is the kernel view as we discussed before.
It restricts access to code in data inside of the vault while at the same time it of course
allows access to the remaining parts of the kernel.
The second is the vault view.
It grants access permissions to the memory within the vault.
So basically yes.
And to show how it works in practice we look at the following slides.
So like we said before during early boot the kernel communicates designated entry points
into the vault with the underlying security support layer.
So these entry points define the vault's interface and they comprise addresses of selected
function entries inside of the vault.
This means only branches to these specific entry points are authorized to enter the vault.
So when the kernel jumps to one of these entry points the system will trap the execution
attempt and end over control flow to the underlying security support layer.
Then the security support layer compares to trapped address against the set of authorized
entry points and only if the check passes the VMM switches to the vault view allowing
the kernel execution to proceed from inside of the vault.
If there is a need to temporarily exit the vault for example to call a function an external
function that is not part of the vault or due to an interrupt the underlying security
support layers which is back to the kernel view and this way the system basically temporarily
closes the vault and maintains its integrity.
This soon as the interrupt handler finishes its execution the system can reenter the
vault.
For this the VMM must verify that the vault was opened legitimately in the first place and
second the return address must match the location of the initially exited of the
vault.
The address must match the location that initially exited the vault and finally as soon
as the execution reaches its designated exit point the VMM closes the vault and this
completes the life cycle of the vault.
Now as we saw the vault lengthens itself perfectly to reinforce something like the patching
and tracing facility and their data structures but what about key probes and I have explicitly
not mentioned key probes in my list before and the reason for this is that I believe
key probes deserve a special issue so key probes combined with ppf program serve as a
foundation for advanced tracing and security frameworks however their extensive flexibility
presented WF sword so key probes allow to place hooks at almost any locations in the
kernel and this poses significant challenges when we try to authenticate the patching
attempts.
Now overall key probes presents a great tool for debugging, profiling, generating security
events more but they can become an interest tool in the wrong hands.
Because of this my question to the community is well how do you believe could vass reduce
the tax surface of key probes and I'm sure there's a number of scenarios in which for
example the the vault technology could assist the current security state of k probes however
as this had we have yet to pinpoint the definite solution with this regard so if you have
suggestions or would like to discuss topics please feel free to reach out we are
let's collaborate and then basically talk about your ideas.
So at this point I would like to conclude this presentation with an outlook and also a call
for action so in summary I can say that there is still a lot left to investigate.
We at Blurock security will continue investigative techniques that allow us to further
alleviate the strict well strict separation between the Linux kernel and AVMM.
We truly believe that virtualization extensions can become inner and building blocks of
the Linux kernel. At the same time we would like to engage with the Linux community so
Blurock's best Linux kernel as well as the Nova Microwiser are both open source.
It one of our next goals is to start preparing patches to get at least a part of our
code base into into main land. Also from what I can tell virtualization system security
receives increasing attention from the industry so software companies like Microsoft Samsung
away and of course more seem to put us strong emphasis on virtualization system security.
So we are open to start discussions in order to define a common hypervisor hypervisor
hypervisor hyprical interface for Linux that would meet the requirements for all parties.
Now at the end of this presentation I still claim that virtualization system security
has not been explored to its full extent and because of this I look forward to further research
basically investigating new avenues of virtualization that are yet to be discovered.
This concludes my presentation. Thank you very much.
All right I was like this short on time for questions but I'm sure you can you can go outside
and anyone who's got questions about it can come meet you very easily. Thank you. Perfect.