<!doctype html>
<html>
<head>
<meta charset="utf-8">
<title>Betrusted: Something-Something Secure</title>
<meta name="description" content="A framework for easily creating beautiful presentations using HTML">
<meta name="author" content="Sean "xobs" Cross">
<meta name="apple-mobile-web-app-capable" content="yes">
<meta name="apple-mobile-web-app-status-bar-style" content="black-translucent">
<meta name="viewport" content="width=device-width, initial-scale=1.0, maximum-scale=1.0, user-scalable=no">
<link rel="stylesheet" href="css/reveal.css">
<link rel="stylesheet" href="css/theme/lca2020.css" id="theme">
<!-- Theme used for syntax highlighting of code -->
<link rel="stylesheet" href="lib/css/zenburn.css">
<!-- Printing and PDF exports -->
<script>
var link = document.createElement('link');
link.rel = 'stylesheet';
link.type = 'text/css';
link.href = window.location.search.match(/print-pdf/gi) ? 'css/print/pdf.css' : 'css/print/paper.css';
document.getElementsByTagName('head')[0].appendChild(link);
</script>
<!--[if lt IE 9]>
<script src="lib/js/html5shiv.js"></script>
<![endif]-->
<style>
/*********************************************
* ZOOM REVERSE TRANSITION (i.e. zoom out)
*********************************************/
.reveal .slides section[data-transition=zoomrev],
.reveal.zoomrev .slides section:not([data-transition]) {
transition-timing-function: ease;
}
.reveal .slides > section[data-transition=zoomrev].past,
.reveal .slides > section[data-transition~=zoomrev-out].past,
.reveal.zoomrev .slides > section:not([data-transition]).past {
visibility: hidden;
-webkit-transform: scale(0.2);
transform: scale(0.2);
}
.reveal .slides > section[data-transition=zoomrev].future,
.reveal .slides > section[data-transition~=zoomrev-in].future,
.reveal.zoomrev .slides > section:not([data-transition]).future {
visibility: hidden;
-webkit-transform: scale(16);
transform: scale(16);
}
.reveal .slides > section > section[data-transition=zoomrev].past,
.reveal .slides > section > section[data-transition~=zoomrev-out].past,
.reveal.zoomrev .slides > section > section:not([data-transition]).past {
-webkit-transform: translate(0, 150%);
transform: translate(0, 150%);
}
.reveal .slides > section > section[data-transition=zoomrev].future,
.reveal .slides > section > section[data-transition~=zoomrev-in].future,
.reveal.zoomrev .slides > section > section:not([data-transition]).future {
-webkit-transform: translate(0, -150%);
transform: translate(0, -150%);
}
</style>
</head>
<body>
<!-- Start of main presentation -->
<div class="reveal">
<div class="footer">
<a class="url" href="https://p.xobs.io/lca20-bt/">p.xobs.io/lca20-pif</a>
<span class="theme">Who’s Watching</span><span class="hashtag"> | #LCA2020</span><span class="twitter"> |
@linuxconfau</span>
</div>
<div class="commentary"></div>
<div class="slides">
<section data-background-image="css/theme/lca2019-title-bg-transparent.svg">
<h2 style="background-color: transparent;">Betrusted: Being Secure</h2>
<h5 style="background-color: transparent;">That's no Blackberry, it's a chat client!</h5>
<p align="right" style="margin-bottom: 0px; margin-top: 0px; line-height: 1;">
<small>bunnie - <a href="https://bunniestudios.com/">https://bunniestudios.com/</a> - @bunnievorpal</small>
</p>
<p align="right" style="margin-bottom: 0px; margin-top: 0px; line-height: 1;">
<small>Tom Marble - <a href="https://info9.net/wiki/tmarble/">https://info9.net/wiki/tmarble/</a></small>
</p>
<p align="right" style="margin-bottom: 0px; margin-top: 0px; line-height: 1;">
<small>Sean Cross - <a href="https://xobs.io/">https://xobs.io/</a> - @xobs</small>
</p>
</section>
<section>
<section>
<h2>Xous: Why another kernel?</h2>
<aside class="notes">
A big question that gets asked is -- why another kernel? Why don't we just
put Linux on it and be done with it? Or something else like Minix, TockOS,
or FreeRTOS?
</aside>
</section>
<section>
<h2>Betrusted Goals</h2>
<ul>
<li><=4 MB RAM</li>
<li>Process Isolation</li>
<li>Safe language</li>
<li class="fragment">Microkernel</li>
</ul>
<aside class="notes">
With Betrusted, we wanted to reduce the code footprint. This will allow
us to run with less RAM -- ideally 4 MB or less. We also wanted to have
a full MMU, which is somewhat unusual in the embedded microcontroller
space, where a more limited Memory Protection Unit is preferred.
We would like to have full process isolation, so even if one process is
compromised, attackers will have a harder time boring through the system
to gain a more complete takeover.
Therefore, we would like Betrusted to run a Microkernel-style operating
system, with "servers" that provide features such as the display,
keyboard, and even basic task switching. These should all run in
userspace with the bare minimum permissions required to get the job done.
Finally, we would like to have the operating system written in a safe
systems language.
</aside>
</section>
<section>
<h2>Rust: Safety, Speed, Concurrency</h2>
<aside class="notes">
The Rust programming language promises the holy trifecta: Safety, Speed,
Concurrency. Pick any three. If you're going to start over on a systems-
level project, choose Rust. There will be a lot of wailing and gnashing
of teeth to begin with, but the end result will be better.
When we started Betrusted, we decided that it should primarily use Rust
as the systems language. That way we can be sure that our code is sound.
Additionally, Rust has the ability to produce efficient binaries, and the
efficiency is only going to get better as time progresses.
This eliminates non-Rust choices such as Linux or Minix.
</aside>
</section>
<section>
<h2>A Survey of Rust-based Operating Systems</h2>
<aside class="notes">
Having decided to use Rust, we did a survey of Rust-based operating
systems. There are several available, in various states of completeness.
The two biggest candidates are Redox and Tock.
</aside>
</section>
<section>
<h2>Rust-based Operating Systems: Tock</h2>
<aside class="notes">
Tock is the most obvious choice, since it already has a RISC-V port
and is supported by a well-documented ABI. Tock supports multiple
tasks written in either Rust or C, which is a very nice feature.
However, Tock does not support an MMU. It would be possible to adapt
the MPU interface to work with an MMU, but a lot of design work has
gone into Tock to make it work well with only the standard MPU that
is present on most ARM chips. Using Tock would be asking it to do
something that it's not designed for. Instead, it's better to pick
the right tool for the job.
Additionally, the Tock message passing infrastructure assumes only
one server per process, which can limit flexibility.
</aside>
</section>
<section>
<h2>Rust-based Operating Systems: Redox</h2>
<aside class="notes">
Redox is the other large Rust-based operating system, and is the most
compelling. Redox is currently limited to x86-64 (with a plan to
port it to AArch64), so we would need to port it ourselves to RISC-V.
The biggest problem with Redox is its size: It's a full Desktop
operating system, and supporting it on Betrusted would require us to
spend a lot of time cutting it down to just the bare microkernel,
at which point we can start to recreate everything ourselves. The
kernel itself is such a small part of Betrusted. Besides, we would
like the freedom to experiment, to randomize the syscall numbers and
have keepout areas of the screen and add IMEs to the input, which
would quickly introduce incompatibility with Redox.
Finally, we would like to be able to use stable Rust for our applications,
which we can almost do with Xous. We're just waiting for either the
"alloc_error_handler" attribute to be stabilized (issue 66740), or
defaulting handle_alloc_error to panic (issue 66741), which would give
us everything we'd need to use alloc on stable Rust.
In short, Tock is too small, and Redox is too big.
</aside>
</section>
<section>
<h2>Other Alternatives and Inspirations</h2>
<aside class="notes">
There are many alternative operating systems. We can draw inspiration
from them, even if we don't use them directly.
For example, both the QNX microkernel and Solaris Doors implementation
allow for one process to pass a message to another, which then inherits
its remaining quantum and runlevel. This prevents priority inversions
and makes syscalls relatively cheap.
</aside>
</section>
</section>
<section>
<section>
<h2>Xous: System Design</h2>
<aside class="notes">
Xous is, currently, very much under development. However, there has
been a lot of planning.
</aside>
</section>
<section>
<h2>Xous: Memory Model</h2>
<aside class="notes">
Xous will base its memory model on the Rust borrow checker. That is,
shared memory will be used for IPC. If one process wishes to get a
response from another, it can pass pages via a mutable borrow. If
a process wishes to share pages across multiple process, then only an
immutable borrow may be made, and the sharing process cannot access
pages until all processes have returned the memory.
A process can move memory into another, which for example is how
process spawning works. In such a case, memory is no longer available
in the sending process.
</aside>
</section>
<section>
<h2>Xous: Missing Features</h2>
<aside class="notes">
Xous has no fork(). Instead it will have spawn().
Shared libraries aren't available at the start, but may come later.
</aside>
</section>
</section>
</div>
</div> <!-- class="reveal" -->
<!-- End of main presentation -->
<!-- Start of configuration section -->
<script src="lib/js/head.min.js"></script>
<script src="js/reveal.js"></script>
<script>
var presenter = !!Reveal.getQueryHash().s;
// More info https://github.com/hakimel/reveal.js#configuration
Reveal.initialize({
controls: presenter ? false : true,
progress: true,
history: true,
center: false,
controlsTutorial: presenter ? false : true,
slideNumber: presenter ? null : 'c/t',
// The "normal" size of the presentation, aspect ratio will be preserved
// when the presentation is scaled to fit different resolutions. Can be
// specified using percentage units.
width: 960,
height: 700,
// Factor of the display size that should remain empty around the content
margin: 0.1,
multiplex: {
url: 'https://p.xobs.io/',
id: 'd03979a76e514b4c',
secret: Reveal.getQueryHash().s || null
},
// Bounds for smallest/largest possible scale to apply to content
minScale: 0.02,
maxScale: 5.5,
transition: 'slide', // none/fade/slide/convex/concave/zoom
// More info https://github.com/hakimel/reveal.js#dependencies
dependencies: [
{ src: 'lib/js/classList.js', condition: function () { return !document.body.classList; } },
{ src: 'plugin/markdown/marked.js', condition: function () { return !!document.querySelector('[data-markdown]'); } },
{ src: 'plugin/markdown/markdown.js', condition: function () { return !!document.querySelector('[data-markdown]'); } },
{ src: 'plugin/highlight/highlight.js', async: true, callback: function () { hljs.initHighlightingOnLoad(); } },
{ src: 'plugin/search/search.js', async: true },
{ src: 'plugin/zoom-js/zoom.js', async: true },
{ src: 'plugin/notes/notes.js', async: true },
{ src: 'lib/js/socket.io.js', async: true },
{
src: presenter ?
'plugin/multiplex/master.js' :
'plugin/multiplex/client.js', async: true
},
]
});
Reveal.addEventListener( 'slidechanged', function( event ) {
// event.previousSlide, event.currentSlide, event.indexh, event.indexv
var commentaries = document.getElementsByClassName("commentary");
Array.prototype.forEach.call(commentaries, cmt => {
cmt.innerHTML = "";
});
// debugger;
event.currentSlide.childNodes.forEach(element => {
if ((element.nodeName == "ASIDE") && (element.className == "notes")) {
Array.prototype.forEach.call(commentaries, cmt => {
cmt.innerHTML = "<p>" + element.innerHTML.replace("\n\n", "</p><p>") + "</p>";
});
}
});
} );
</script>
</body>
</html>