Add report on the nested kernel project
Approved by: hrs (mentor, implicit)
This commit is contained in:
parent
1b22bc5abe
commit
edae37d14f
Notes:
svn2git
2020-12-08 03:00:23 +00:00
svn path=/head/; revision=46554
1 changed files with 160 additions and 0 deletions
|
@ -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&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 — 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>
|
||||
|
|
Loading…
Reference in a new issue