-
Notifications
You must be signed in to change notification settings - Fork 3
/
index.xml
132 lines (132 loc) · 12.1 KB
/
index.xml
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
<channel>
<title>Immunant, Inc</title>
<link>/</link>
<description>Recent content on Immunant, Inc</description>
<generator>Hugo -- gohugo.io</generator>
<language>en-us</language>
<copyright>Immunant, Inc.</copyright>
<lastBuildDate>Fri, 05 Apr 2024 00:00:00 +0000</lastBuildDate>
<atom:link href="/index.xml" rel="self" type="application/rss+xml" />
<item>
<title>In-process Sandboxing with Memory Protection Keys</title>
<link>/blog/2024/04/sandboxing/</link>
<pubDate>Fri, 05 Apr 2024 00:00:00 +0000</pubDate>
<guid>/blog/2024/04/sandboxing/</guid>
<description>Modern software applications contain many distinct smaller components, such as libraries or plugins, that are often written by third-parties. Developers typically don’t have the resources to exhaustively review and scrutinize third-party source code, leaving application integrators and operational teams with little visibility into the security and correctness of this code. These libraries provide specialized functionality, and often do not need access to the entire application, but the status quo is that an application is an amalgamation of all this code into one process with all components having equal access to all data in the application.</description>
</item>
<item>
<title>Emitting Safer Rust with C2Rust</title>
<link>/blog/2023/03/lifting/</link>
<pubDate>Wed, 11 Jan 2023 00:00:00 +0000</pubDate>
<guid>/blog/2023/03/lifting/</guid>
<description>In this post, we will discuss recent results from Immunant and Galois in extending C2Rust to emit memory-safe Rust in certain cases. With this work we aim to shift a meaningful part of the translation burden from the human to the machine. Up until now, C2Rust has only been able to translate C to unsafe Rust that is no safer than the original input C code. Although this provides a starting point for manual refactoring into idiomatic and safe Rust, this work had to be done by the human.</description>
</item>
<item>
<title>C2Rust is Back</title>
<link>/blog/2022/06/back/</link>
<pubDate>Tue, 14 Jun 2022 00:00:00 +0000</pubDate>
<guid>/blog/2022/06/back/</guid>
<description>tl;dr: c2rust (a transpiler from C to unsafe Rust) is once more being actively developed, now works with recent nightlies, has some new features and bugfixes, and has dropped the c2rust-refactor tool in preparation for an exciting new approach to generating safe rust. As always, we welcome new users and are eager for any feedback!
After a long while without much time or funding to dedicate to the project, c2rust is once more being updated and actively maintained by Immunant in collaboration with our friends at Galois.</description>
</item>
<item>
<title>Refactoring Rust Transpiled from C</title>
<link>/blog/2020/09/transpiled_c_safety/</link>
<pubDate>Tue, 01 Sep 2020 00:00:00 +0000</pubDate>
<guid>/blog/2020/09/transpiled_c_safety/</guid>
<description>Memory management errors are responsible for 70 to 80 percent of security vulnerabilities1 2. This would be much less of a problem if computers were running more Rust and less (if any) C code.
So do we rewrite every widely used C project in Rust? Doing so entirely by hand is infeasible. Doing so in an entirely mechanized way is impossible. Between these extremes lies a point that strikes the optimal balance between the efficiency of automation and the intelligence of humans.</description>
</item>
<item>
<title>Transpiling A Kernel Module to Rust: The Good, the Bad and the Ugly</title>
<link>/blog/2020/06/kernel_modules/</link>
<pubDate>Mon, 01 Jun 2020 00:00:00 +0000</pubDate>
<guid>/blog/2020/06/kernel_modules/</guid>
<description>Earlier this year, we used the C2Rust framework to translate applications such as Quake 3 to Rust. In this post, we&rsquo;ll show you that it is also possible to translate privileged software such as modules that are loaded by the Linux kenel. We&rsquo;ll use a small, 3-file kernel module which is part of the Bareflank Hypervisor SDK developed by Assured Information Security but you can use the same techniques to translate other kernel modules.</description>
</item>
<item>
<title>Bitfields Forever: Why we need a C-compatible Rust Crate</title>
<link>/blog/2020/01/bitfields/</link>
<pubDate>Mon, 27 Jan 2020 00:00:00 -0800</pubDate>
<guid>/blog/2020/01/bitfields/</guid>
<description>What Are Bitfields? The C programming language is a product of a time where it was important to use as few resoures as possible. Memory was measured in kilobytes rather than gigabytes as we do today. Bitfields offer a handy way to reduce memory usage. However, bitfields aren&rsquo;t just a relic of yesteryear&rsquo;s computer programming; they remain frequently used today. Some domains, like embedded hardware, still require programmers to be frugal with memory.</description>
</item>
<item>
<title>Translating Quake 3 into Rust</title>
<link>/blog/2020/01/quake3/</link>
<pubDate>Mon, 06 Jan 2020 00:00:00 +0000</pubDate>
<guid>/blog/2020/01/quake3/</guid>
<description>The Rust-loving team at Immunant has been hard at work on C2Rust, a migration framework that takes the drudgery out of migrating to Rust. Our goal is to make safety improvements to the translated Rust automatically where we can, and help the programmer do the same where we cannot. First, however, we have to build a rock-solid translator that gets people up and running in Rust. Testing on small CLI programs gets old eventually, so we decided to try translating Quake 3 into Rust.</description>
</item>
<item>
<title>Source Code Linking: Merging C Headers into Rust Modules</title>
<link>/blog/2019/12/header_merging/</link>
<pubDate>Wed, 18 Dec 2019 16:00:00 -0800</pubDate>
<guid>/blog/2019/12/header_merging/</guid>
<description>Producing readable, idiomatic Rust code is a major goal of C2Rust, our project to accelerate migration of C code into Rust. One hurdle we faced is the mismatch between C headers and the Rust module system. C and Rust are similar in many ways: they&rsquo;re both performance oriented languages with explicit memory management and full control over every aspect of the system. Rust&rsquo;s module system is a huge improvement over C header files.</description>
</item>
<item>
<title>Rust 2020: Lessons learned by transpiling C to Rust</title>
<link>/blog/2019/11/rust2020/</link>
<pubDate>Tue, 12 Nov 2019 00:00:00 +0000</pubDate>
<guid>/blog/2019/11/rust2020/</guid>
<description>The C2Rust project is all about translating C code into an equivalent, drop-in ABI-compatible Rust implementation. (Read our C2Rust introductory blog post here.) Along the way we&rsquo;ve uncovered some dark corners of C as it&rsquo;s written in practice, and found places where Rust can&rsquo;t quite replicate the same code with the same ABI. This is the story of those dark corners and the areas we think Rust needs to improve to be fully FFI compatible with C.</description>
</item>
<item>
<title>Improved C Variadics in Rust and C2Rust</title>
<link>/blog/2019/09/variadics/</link>
<pubDate>Tue, 17 Sep 2019 00:00:00 +0000</pubDate>
<guid>/blog/2019/09/variadics/</guid>
<description>Introduction to C Variadics The C language provides a special class of functions called variadic functions that can be called with a variable number of arguments. The declaration of a variadic function ends with an ellipsis, e.g.:
void variadic_function(int x, ...); Variadic functions can be called with any number of arguments in place of the ellipsis (including none at all).
The C runtime provides a set of helper macros that developers use to retrieve the values of the variadic arguments.</description>
</item>
<item>
<title>Introduction to C2Rust</title>
<link>/blog/2019/08/introduction-to-c2rust/</link>
<pubDate>Fri, 16 Aug 2019 00:00:00 +0000</pubDate>
<guid>/blog/2019/08/introduction-to-c2rust/</guid>
<description>We believe that software should be both fast and safe. Languages like C and C++ deliver blazingly fast performance but are pretty much impossible to use safely. Software mitigations built into the operating system make exploitation of buggy code much harder but attackers are amazing at finding ways to bypass new defenses. What we really need is a way to eliminate the source of memory corruption bugs. Rust delivers on speed and interoperability while making memory safety the default.</description>
</item>
<item>
<title>Contact Us</title>
<link>/contact/</link>
<pubDate>Tue, 21 May 2019 00:00:00 +0000</pubDate>
<guid>/contact/</guid>
<description> Name: Email: Message: Send Message </description>
</item>
<item>
<title>Message Sent</title>
<link>/thanks/</link>
<pubDate>Tue, 21 May 2019 00:00:00 +0000</pubDate>
<guid>/thanks/</guid>
<description>Thanks for reaching out; we&rsquo;ll be in touch shortly.</description>
</item>
<item>
<title>Optimizing for Security</title>
<link>/blog/2018/09/multicompiler/</link>
<pubDate>Mon, 10 Sep 2018 00:00:00 +0000</pubDate>
<guid>/blog/2018/09/multicompiler/</guid>
<description>It is obviously very bad if everybody used the same password. It is also bad when one person reuses the same password across sites. Luckily, we have password managers that can generate unique, random passwords for each site. It is no less of a problem when everybody runs the same software for the following reason: When a software flaw is found, we want every installation of the program to be different enough that the same malicious input cannot compromise multiple users (but not so different that users notice).</description>
</item>
<item>
<title>Code Migration</title>
<link>/migrating/</link>
<pubDate>Tue, 20 May 2014 00:00:00 +0000</pubDate>
<guid>/migrating/</guid>
<description>The risks of memory safety bugs are well understood. Even expert developers struggle to correctly use C/C++. In the best case scenario, the development process is augmented by an array of bug finding tools such as fuzzers and static analyzers. Even so, we know that memory safety bugs invariably make it into the released code where they will be found by attackers.
For instance, Microsoft reported that over the last 12 years, 70% of Microsoft security patches address memory safety bugs.</description>
</item>
<item>
<title>Hardening and Exploit Mitigation</title>
<link>/mitigating/</link>
<pubDate>Tue, 20 May 2014 00:00:00 +0000</pubDate>
<guid>/mitigating/</guid>
<description>Need to process untrusted inputs with C/C++? Oftentimes, security best practices do not get implemented; limited resources causes things to slip through the cracks. Our expert security engineers work alongside your team to measurably increase the security of your product. Whether you rely on software developed in house or third party/open source libraries, we will help you assess your current security posture and deploy additional software hardening techniques without degrading overall system performance.</description>
</item>
<item>
<title>Software Isolation</title>
<link>/isolation/</link>
<pubDate>Tue, 20 May 2014 00:00:00 +0000</pubDate>
<guid>/isolation/</guid>
<description>Not all code is equally trustworthy - third-party libraries are a necessary but risky part of complex software. These libraries are often not audited or written to the same security standards as the core of your application, but have equal access to sensitive data. A vulnerability in a dependency is just as damaging as a vulnerability in first-party code.
To prevent security issues in one component from compromising the entire application, we isolate components into separate compartments.</description>
</item>
</channel>
</rss>