[Cryptography] "NSA-linked Cisco exploit poses bigger threat than previously thought"
Kent Borg
kentborg at borg.org
Wed Aug 24 17:48:28 EDT 2016
It was quite clever of C to make pointers and arrays and strings all the
same, it was efficient and elegant, but it brought dangers. Critics have
always been dismissed, with the implication that they are not Real
Programmers.
"We are adults, we program carefully, this won't be a problem."
Except it has not worked. That clever unity of pointers and arrays and
strings is still burning us, both in very old code and in new.
Arguing that any reaction is pointless, that it will always be possible
to write bugs, is kind of like arguing that it will always be possible
to crash an airplane. Okay, what's the point? All efforts are futile?
"Lecture the programmers harder. Don't make mistakes!"
Hmmm.
Disclaimer: The following might contain mistakes.
From what I understand Rust manages to be as small and fast as C, yet
as safe as Python/Java, even suitable for systems programming.
"Wait, safe *and* I can write device drivers?"
Not quite. If you have to do unsafe things (directly manipulate a
pointer, touch hardware, etc), you have to do that in a block of code
that is marked "unsafe". Be really careful in there, be ready to defend
to your colleagues both the details of your unsafe code, and that the
unsafe block need be there at all.
Where every line of a C program is dangerous, in Rust you can grep for
them all.
Yes, Rust has an odd syntax for a C programmer.
The compiler is also very picky, figuring out how to make it happy can
apparently be frustrating, but once you do there are whole classes of
bugs that won't be there.
Possibly the most onerous thing about Rust is it obligates the
programmer to specify ownership of all allocated data. Passing data to a
function? Okay, but are you passing ownership of that data or are you
just lending it? This has to be explicit. The benefits, however, are
great: use after free or before allocation is no longer a problem, and a
bunch of bugs endemic to multithreaded code also go away. So though Rust
requires programs to be explicit about ownership, the programmer then no
longer has to implement all that error-prone data-locking by hand.
To make array bounds checking fast Rust offers higher level access
mechanisms, similar to Python's slices: If the programmer doesn't manage
array indexes by hand, then Rust doesn't need to runtime check them!
(Rust compiler trusts its own code generation.) What if you have an
access pattern that you can't efficiently express in Rust? Okay, maybe
just pay the bounds-checking cost, or maybe you need a small block of
unsafe code: Be careful in that handful of lines. Be as careful as you
should always be in C. Examine your unsafe block, have it reviewed, test
it. Be skeptical.
Most of Rust's safety comes from compile-time static analysis (that's
why the compiler is annoying). This means Rust is fast, and its runtime
code can be (depending on what libraries you use) very nearly as small
as that of C. Far smaller than Java, and I think even smaller than C++.
Oh, and there is no garbage collector, seems the compile time approach
works and there is no need. And though Rust might be a little bizarre,
is it not as bizarre as something like Erlang!
We have a crisis. Our software is riddled with low-level bugs and it is
only getting worse. I don't know whether Rust will be successful, but it
seems quite clear that programmers are not capable of handling C's
clever pointer/array/string-unity. What other languages are suitable for
"I need every drop of performance and control", yet are this safe?
Serious question. A question we should be asking.
Forgive me for going on so long with something that is not strictly
crypto-related, but Rust is new technical ground for most of us, and
crypto code also has these low-level bugs. Rust might help.
-kb
More information about the cryptography
mailing list