Add report on the nested kernel project
Approved by: hrs (mentor, implicit)
This commit is contained in:
Benjamin Kaduk
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>
|
<sponsor>The &os; Foundation</sponsor>
|
||||||
</project>
|
</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>
|
</report>
|
||||||
|
|
|
||||||
Loading…
Reference in a new issue