
Towards Linux Kernel Memory Safety - lainon
https://arxiv.org/abs/1710.06175v1
======
anameaname
Source for those interested:
[https://github.com/torvalds/linux/blob/master/lib/refcount.c](https://github.com/torvalds/linux/blob/master/lib/refcount.c)

I'm kind of surprised that the authors went with compare-and-exchange for
their ref count, rather than get-and-increment. Even if the counter does
overflow, it's usually detectable, and reversible. This is true even in the
face of concurrent updates. The benefit is that there is only one atomic
operation in the fast path.

~~~
Someone
” _usually_ detectable” isn’t good enough. You must assume attackers will try
to hit your code zillions of times until they hit the ‘unusual’ case.

------
fulafel
The MPX part was a good excuse to look around at the status of MPX support. It
seems GCC is the major compiler to support it, but it's under threat of
depreciation because the bootsrap build with MPX has been broken for so long.
Also the lack of AMD buy-in (patents?) seems like a big hinderance compared to
more compatible compiler-based approaches for C memory safety, like SoftBound,
CCured, etc.

~~~
pjmlp
The problem with any of such approaches, versus safer languages, is that they
only work properly if 100% of the source code is available.

~~~
joosters
I don't understand your point. If you haven't got all the source code (e.g.
random drivers), you're unlikely to have any say in the language that the
binary code blobs were written in either.

~~~
pjmlp
Languages like Ada just forbid many of the errors that lead to memory
corruption in C, by default.

So it would only happen with a binary Ada library in two ways:

\- the binary was manipulated and thus does not map to the original source
code

\- the code was compiled with permission for _Uncheked_ packages enabled

In C, 100% of the source code is unsafe, specially when compiled with -O3.

~~~
joosters
I was referring to your original comment: ' _they only work properly if 100%
of the source code is available._ '

This project is adding protection to the linux kernel. Now, this bounds
checking could be added to a kernel build with 100% of the source code
available, in which case all is good. Or, it could be added to a kernel build
where some of the drivers are available only in a 'binary blob' form. In which
case, rewriting the kernel in Ada (or whatever) would not help you with the
binary blobs, since they are out of your control. So, as I understand it, your
point of 'only working properly if 100% of the source code is available' would
seem to be just as true for a code rewrite as it is for the paper's approach
to the problem.

------
empath75
Long term, the solution has to be switching to an OS that’s written in a
memory safe language.

~~~
StudentStuff
So Rust it is then, eh? Could work through the kernel module by module to
rewrite it in rust, but it'd be a multi-year process (like Firefox's rewrite
has been).

~~~
ynezz
You mean rewriting unsafe C code to Rust by annotating it with `unsafe`
keyword? :-) Try to write in Rust something which would touch bare metal
hardware. It would be PITA, it would be full of unsafe keywords and assembler
code so it would possibly result in similar amount of bugs in the end, just in
different parts.

~~~
dikaiosune
This is empirically not true if you look at the usage of unsafe in pure Rust
kernels. Yes, there is assembly needed, and some unsafe Rust code, but it's
very possible to wrap up unsafe operations in safe APIs.

For example, the kernel repository for Redox (a written-in-Rust OS project)
appears to have 242 usages of the unsafe keyword (including comments bc lazy),
out of 18205 lines of Rust source.

------
DSingularity
Can anyone here comment on the races in MPX and whether this will prevent
deployment?

[https://intel-mpx.github.io/microbenchmarks/#multithreading](https://intel-
mpx.github.io/microbenchmarks/#multithreading)

------
youdontknowtho
This is really cool. I would love to hear more about this. Those bounds
checking instructions will hopefully make a big difference.

------
lima
Is this PAX_REFCOUNT or something entirely new?

