Hacker News Reader

I'm baffled by that opinion. The fact that memory-unsafe software keeps on being produced in C/C++ is a good thing? The capabilities of criminals to run local (or remote!) root exploits on many devices is offset by the fact that some hackers can tinker with them?

Freedom should be achieved in different ways. Please don't make freedom and security contradictions.

Yes, it's definitely controversial but I think a little bit of insecurity is a good thing but not too much -- the question is how much. Consider that had the NSA been far more secure in their processes, the whole Snowden thing may have never happened... which is somewhat ironic.

> Freedom should be achieved in different ways. Please don't make freedom and security contradictions.

In an ideal world, they wouldn't be. Unfortunately that's not how it is in reality.

So what do you think about the NSA's capabilities to easily rootkit your "free" exploitable device? I don't think this is a consistent worldview.

Freedom is not about consistency in everything.

I've never said that freedom is about consistency. Opinions should be consistent if they are to be taken seriously.

This guy wants to intentionally leave software exploitable, ready to be unknowingly hacked by criminals or governments, and call it freedom. And he gets upvoted for it!

What's not consistent?

Also, it seems that "criminals" are the new "terrorists".

To play a devil's advocate, I want to answer this directly as answered.

Available information indicates that NSA used various coercion tactics to ensure cooperation from various companies and that it has the methods to ensure hardware modifications in its own interests.

So the damage to NSA from improving security too much is less than damage to my ability to use the computing device I have paid for as an actual computing device.

Of course we should also consider smaller threats.

But the better the platform is locked down, the less limitations there ae for advertiser-friendly platform design, which makes people expect a lot of permissions requested by applications, so phishing and trojans become easier.

The problem here is about the effects of scale: it is hard to produce just a few thousands phones with good specs.

That freedom also means I have the freedom to modify my device after exploiting it in order to remove those exploits. On the other hand, a device that is completely unexploitable due to being written in a strongly safe language, would mean I no longer have that freedom - and while it may be unexploitable to everyone else, I'm pretty sure the NSA has its ways to get in anyway; if it does, then there's no escape.

So, you like languages that are prone to obscure bugs because they allow you to remain competitive with the NSA?

Practical experience shows that once you run into even routine systems programming elements, like writing device drivers and whatnot, you eventually have to concede some safety, or end up with an unprogrammable behemoth of such baroque complexity that you likely have more security holes, just of some other kind. There has been a lot of research into this back in the 1990s; most of the useable results produced security by architecture rather than tools.

It's almost as if what one would want is a language where you could shrink unsafe operations to as small a footprint as possible by confining them within a block with a special keyword, like this:

     unsafe { … }

Someone should invent such a thing.

Edit: …yeah, I was being tongue-in-cheek. This is exactly what Rust provides.

http://doc.rust-lang.org/rust.html#unsafety

"...When a programmer has sufficient conviction that a sequence of potentially unsafe operations is actually safe, they can encapsulate that sequence (taken as a whole) within an unsafe block. The compiler will consider uses of such code safe, in the surrounding context…"

- http://msdn.microsoft.com/library/chfa2zb8.aspx

- http://doc.rust-lang.org/rust.html#unsafe-blocks

If I call a function that is running unsafe { } inside of it, do I know? Because I really want to know. And I want my function to be marked as unsafe as well (because it is) as well as any function calling my function, etc.

You don't know, but you can use a compiler flag that will tell you if you are.

> I want my function to be marked as unsafe as well (because it is)

This misunderstands the nature of `unsafe`. `unsafe` means "I promise that this is actually safe, even thought it can't be inferred." Take, for example, a type which has mutable, shared state, but enforces all access through a mutex[1]. This type presents a safe interface, but the compiler can't know that it's safe, so you have to use `unsafe` internally.

1: http://static.rust-lang.org/doc/master/std/cell/struct.RefCe...

> If I call a function that is running unsafe { } inside of it, do I know? Because I really want to know.

Pretty much every function is going to be transitively running unsafe code, since the core libraries use it to implement the base primitives.

It should be noted that the unsafe code in the core libraries is kept to a minimum and (at least in theory) heavily scrutinized.

All code in mozilla/rust gets a code review before landing, so there's always at least 2 sets of eyes on it.

The way that you mark a function as unsafe is to stick a keyword in front of it:

  unsafe fn foo() { ... }

Any function marked as such is then allowed to call other unsafe functions:

  unsafe fn bar() { foo(); }

But there is a way to break the chain, which is to use an `unsafe` block without marking your function as unsafe:

  fn qux() {
      unsafe {
          bar();
      }
  }

That said, it's incorrect to think that Rust is any more unsafe than any other language because of this; most languages simply defer this behavior to their FFI. By pulling it into the language itself, Rust is actually safer than e.g. calling C from Python, because Rust can do the low-level fiddling while still retaining at least some of the safety checks of normal Rust code. Even unsafe Rust is safer than C.

> Even unsafe Rust is safer than C.

This is an important point. `unsafe` blocks only let you do a few extra operations[1], not anything you want. A lot of safety checks still happen inside of unsafe blocks.

1: http://static.rust-lang.org/doc/master/rust.html#behavior-co...

Well, no, you can still theoretically do anything you want, you just need to be very, very explicit about it. :)

Some things are undefined behaviour[1]... so you really don't want to want to do them (i.e. you can do them inside `unsafe`, but the compiler optimises/reasons assuming they never happen: if they occur at all, you could have an arbitrarily broken program).

[1]: http://doc.rust-lang.org/master/rust.html#behavior-considere...

The point that I'm trying to make here is that you cannot make any assumptions about an unsafe block. Anything can happen, including really terrible undefined behavior. But the fact that anything can happen is why Rust is as powerful as C in this area.

My point is that while anything _can_ happen, it's not like Rust just turns off every single check. Yes, they can be gotten around, but it's not like the type system suddenly goes away.

I think a lot of us are somewhat happy with freedom being maintained by the laws of the land. Granted, those do seem under attack, as well. Oddly, by a similar mantra as what leads type safety.

Consider, in a "type safe" law system, intent doesn't matter. Only what you did. Now, look at the laws that run on that principle.

Now, I personally think this is probably orthogonal to type safe programs. But I'm not completely convinced, yet. Type safe programming seems hamstrung by the fact that a type system only really protects that which is specified in the type system. Which seems to mean you can't easily have a variety of ways to do things, as ultimately the type system has to grow to encompass all of the system.

Now, I grant I'm probably just soured by some bad systems in the past where a change to one part required a rework of the entire system.

Most type safe systems have escape hatches that allow for conversion between types.

Also, IME, type safe languages don't hobble me as a programmer. However, the systems and things I work on (and am trying to get work on) have generally well considered specs associated with them. Be it radio protocols, file formats, or whatever. A type safe language (haskell, sml, ocaml, ada, rust (it seems, not explored it much yet), etc.) can really help with these projects. Instead of needing a dictionary translating what magic # 134 means if it's used in this context (god, these old fortran programs break me), we can actually specify things in code in sane, clear ways that map from spec/design to code cleanly. OO, in theory, can help us with this, but it also adds a lot of overhead to create a ton of classes when really we want integers that the compiler knows some are meant to be temperature and some are meant to be pressure. If you start adding temperature and pressure, it flags it. If there's some formula where that actually makes sense, you deliberately, intentionally, explicitly handle the conversion. This is a good thing. Slightly more verbose code, but such a boon for mainenance and v&v work.

Doesn't shock me too much. The experience I have had is when folks basically try to do their programming in the type system. This can work for some cases, maybe all if you "do it right." I've not been lucky enough to see that. Instead, I like it when the types are basically there to help, not force, you.

This is a really frightening post. There is a real tradeoff between security and freedom, but memory safety is not where it manifests. It manifests in the fact that if you give the user power to mess up their system, sometimes they actually do it. However, the dichotomy between freedom and basic memory safety is false and needs to be fought tooth and nail. Your believing it is a minor victory for the corporations you excoriate.

When we build the next generation of free operating system, I want it to be as secure as humanly possible. Your device isn't free if the NSA or some criminal has owned it.

How is it a false dichotomy if things like jailbreaks and console homebrew essentially rely on the lack of memory safety to work?

> Your device isn't free if the NSA or some criminal has owned it.

It's not free if you can't own it either - and that's where the problem lies: how do we stop the secure systems we create from being used and secured against us.

It's a false dichotomy because there's a possible world where you don't have to resort to that crap to get control of the device you bought, where you're in charge at the start (looking back, I wasn't explicit about this, sorry). That's what we should be working on, not holding back the state of the art of programming languages. That's the wrong place to attack the problem.

That would be an ideal world, and I agree that safer languages definitely do make sense there, but the big question is how do we get there.

> That's the wrong place to attack the problem.

Then what do you think is the - currently practical - way to attack the problem?

I think there is a bit of misunderstanding I created in my original post; I'm not completely against security and hate buggy software as much as anyone, but only pointing out that we rely on insecurity for many good things and freedom we have today, and thus we should give more consideration to the implications of using more secure languages before they get to the point of becoming so popular that there is no turning back. They're just such a good fit to be used in trusted computing/DRM systems, and that's what scares me the most.

That fear is akin to governments being afraid of cryptography. The genie's out of the bottle, we know how to make better languages/development environments. The question becomes, do we deliberately hobble ourselves or do we accept the reality and move forward. The "enemy", if they're rational, will be moving towards these better tools. On the other side of the fence, we should as well. Otherwise we're leaving our own code and systems open for abuse.

Ultimately, the only way to correct this is the active encouragement of DRM-free content. The active development of FOSS software. The active development of open-specced hardware. Let's take these tools that let us develop things with fewer errors (or where errors are made blindingly obvious) and make this free world we want.

More freedom for mediocre or bad coders = more ways to fuck up. More freedom for good coders = more ways to make great things (and fuck up).

So basically it's a tradeoff. If people working on the Linux kernel were very careful and good hackers, writing in C would be much less of a risk than letting fresh-out-of-college programmers tinker with memory on the low-level. But even very careful and good hackers can screw up sometimes—see what happened with OpenSSL.

I don't see a reason not to use Rust except for performance, or when the unsafe features of C are required to get the job done. I can't say a lot here because I've only seen Rust's syntax and feature list and never programmed in it. (On the other side, I've written a fair amount of (functioning) code in C, and I feel that debugging race conditions coupled with memory management bugs has shaved a few years off of my expected lifespan already.)

Rust shouldn't be a performance problem. The language semantics allow for all the things that make C fast, as well as doing a better job at aliasing.

Idiomatic Rust will drop a little bit, to the level of idiomatic C++, but there's nothing stopping you from optimizing that to C levels in exactly the same way when necessary.

What about bounds checking and stuff? Sorry for my ignorance on the matter.

It seems you can use unsafe versions of vectors/arrays/strings to bypass bounds checking. Essentially, if you're very confident that your code is correct, then you can speed it up (is it worth it?) to C levels.

On the other hand, a lot of bounds checking is probably going to happen where you'd manually enter it into C/C++ code anyways (if you wanted to avoid certain errors).

Additionally, idiomatic Rust code will employ iterators rather than direct indexing where possible. Rust's iterators are memory safe and do not perform bounds checking.

It appears the compiler optimizes out bounds checking if and only if it can tell during compile time that the index is correct [1]. Arrays of dynamic size or with dynamic references are bound checked. In dynamic cases you should be writing manual bound checking guards in C anyway.

[1]: https://github.com/mozilla/rust/issues/9024

Not only do iterators help avoid them in most cases, I'm anxiously awaiting Intel MPX for more hardware support for bounds checks.

Good post. We need to remember that security is a transitive verb: we secure something against something or someone. As you say, DRM is "securing" a device against the user.

Fortunately Rust has unsafe { ... }

It's interesting to think of an insubordinate dev being tasked to write some horrible locked-down system in Rust and going, "yeah, this thing has to be in an unsafe block because xyz, oh, woops, I guess I introduced a jailbreak opportunity".

Agreed... I'm quite worried about unsafe code in libraries that I'd use.

Not that jailbreaks aren't a good thing, because I'd hate to be forced to use a locked (aka dumb) device.

I doubt that most jailbreaks have anything to do with buffer overflows or pointer bugs in C code.

The iOS jailbreaks used to (haven't followed them recently) involve exploits in C/C++/Objective-C code. They've taken advantage of various system applications to install the jailbreaks. Some used exploits in PDF handling, others in USB handling.

You don't achieve freedom through bad software. What the hell? Note that the NSA spying on you is also facilitated by all the complex, buggy, broken software we use.