Add report on the nested kernel project

Approved by:	hrs (mentor, implicit)
This commit is contained in:
Benjamin Kaduk 2015-04-15 03:47:10 +00:00
parent 1b22bc5abe
commit edae37d14f
Notes: svn2git 2020-12-08 03:00:23 +00:00
svn path=/head/; revision=46554

View file

@ -1851,4 +1851,164 @@ WITHOUT_FORTH=y</pre>
<sponsor>The &os; Foundation</sponsor>
</project>
<project cat='arch'>
<title>Nested Kernel</title>
<contact>
<person>
<name>
<given>Nathan</given>
<common>Dautenhahn</common>
</name>
<email>dautenh1@illinois.edu</email>
</person>
<person>
<name>
<given>Theodoros</given>
<common>Kasampalis</common>
</name>
<email>kasampa2@illinois.edu</email>
</person>
<person>
<name>
<given>Will</given>
<common>Dietz</common>
</name>
<email>wdietz2@illinois.edu</email>
</person>
</contact>
<links>
<url href="nestedkernel.org">Home page for the project that includes links to papers and build instructions.</url>
<url href="http://web.engr.illinois.edu/~dautenh1//downloads/publications/asplos200-dautenhahn.pdf">Conference publication detailing the problem, design, implementation, and evaluation of our prototype.</url>
<url href="http://prezi.com/in6qr3l92ffc/?utm_campaign=share&amp;utm_medium=copy">Presentation on the nested kernel</url>
<url href="https://github.com/HardenedBSD/hardenedBSD/tree/hardened/9/kernsep">HardenedBSD branch of the nested kernel being refactored.</url>
</links>
<body>
<p>This work on a nested kernel architecture is part of
Nathan's doctoral thesis work at the University of Illinois at
Urbana-Champaign. It attempts to improve upon the traditional
monolithic operating sytsem kernel, where a single exploit
anywhere in the kernel grants the attacker full superuser
privileges. The nested kernel operating system architecture
addresses this problem by "nesting" a small, isolated kernel
within a traditional monolithic kernel. This "nested kernel"
interposes on all updates to virtual memory translations to
assert protections on physical memory, thus significantly
reducing the trusted computing base for memory access control
enforcement. We incorporated the nested kernel
architecture into &os; on x86-64 hardware by write-protecting
Memory-Management Unit (MMU) translations and de-privileging the
untrusted part of the kernel, thereby enabling the entire
operating system, trusted and untrusted components alike, to
operate at the highest hardware privilege level. Our
implementation inherently enforces kernel code integrity while
still allowing dynamically loaded kernel modules, thus defending
against code injection attacks. We also demonstrate, by
introducing write-mediation and write-logging services, that the
nested kernel architecture allows kernel developers to isolate
memory in ways not possible in monolithic kernels. The
performance of the nested kernel prototype shows modest
overheads: less than 1% average for Apache, 3.7% average for
sshd, and 2.7% average for kernel compilation. Overall, our
results and experience show that the nested kernel design can be
retrofitted onto existing monolithic kernels, providing defense
in depth.</p>
<p>The basic idea is that the nested kernel initializes the
system so that all page tables are mapped as read-only. Then
all MMU-modifying operations are removed from the untrusted
portion of the kernel; runtime code integrity is enforced by
write-protecting all code pages, marking all non-code
pages as non-executable (NX-bit), and preventing execution of
privileged MMU operations located in userspace mappings
(Supervisor Mode Execution Prevention, SMEP). Because the
nested kernel has control of the page tables it can enforce
these integrity properties leading to virtualization of the
MMU.</p>
<p>The links include a recent conference publication that
details the design, implementation, and evaluation of our
prototype nested kernel architecture on top of &os; 9.0. We are
also bringing up a site with instructions on how to get the
source and build the project. There is also a link to a
presentation on the nested kernel.</p>
<p>We are very interested in feedback on the design of the
nested kernel, and having discussions about how it might get
upstreamed. This is our first time contributing to an open
source project, so even simple advice is likely to be useful.</p>
<p>We are also hoping to gain additional contributors and
interest in the project! The nested kernel has the potential to
enhance commodity operating system design, and &os; is a major
operating system in use today which has high impact. The source
code of our research prototype as evaluated for the paper are in
the process of being made available &mdash; the website and code
are almost ready but may take another week to complete.
However, the implementation is merely a research prototype and
requires significant effort to make production-ready (see the
list of tasks). Some of this work is underway during
refactoring for an implementation in the <a
href="https://www.freebsdfoundation.org/journal/articles">HardenedBSD
project</a>, which is a much cleaner version of the core system
and is integrated into the &os; build system, but is only about
50% completed.</p>
<p>Finally, we have developed an interface to write-protect
data structures in the kernel and are soliciting ideas for uses
of this service. Section 2.4 in the paper details the
interface, and section 4 presents some simple uses of the nested
kernel services. We are interested in ways that the nested
kernel could be used to protect critical kernel data structures
from malware or even just buggy code.</p>
</body>
<sponsor>University of Illinois at Urbana-Champaign</sponsor>
<sponsor>ONR via grant number N00014-12-1-0552</sponsor>
<help>
<task>
<p>Finish implementing core mechanisms: verify DMAP is
properly protected and that we are not using superpages (I think
we have this completed but need to fully verify), full NX
support for all non-kernel code pages (we might need to
specially consider the stack if it is used to execute code),
protect IDT and SMM, and add IOMMU protections. We also need to
do some optimizations where we batch calls into the nested
kernel on process creation (FORK) and mmap operations. The
motivation for these implementation directives can be reviewed
in the paper.</p>
</task>
<task>
<p>Implement SMP functionality and evaluate performance.</p>
</task>
<task>
<p>Port and refactor for a newer version of &os;. The
current implementation is a research prototype and requires some
refactoring to make it clean and consistent, as well as make it
relevant to modern versions of &os;.</p>
</task>
<task>
<p>The nested kernel isolation depends upon certain
hardware instructions to be completely removed from a subset of
the kernel. Therefore, we need to utilize automated linker/loader
techniques to identify and remove privileged MMU operations from
untrusted kernel components to make it maintainable in
practice.</p>
</task>
<task>
<p>Detailed review on the design and implementation with
particular focus on a plan for upstreaming.</p>
</task>
</help>
</project>
</report>