7 ms·

Obligatory comment so nobody else has to: C is a terrible language for security and we must abandon it immediately. Anyone that uses it has clearly not heard of

Obligatory comment so nobody else has to: C is a terrible language for security and we must abandon it immediately. Anyone that uses it has clearly not heard of Go/Rust/Haskell. We should just abandon the Linux kernel and start from scratch. And we can unit test the shit out of it to avoid security vulnerabilities. Hasn't Heartbleed taught us anything? MongoDB is web scale. Ron Paul 2012.

deleted 10y ago
[deleted]
mperham 10y ago
AM I BEING DETAINED, OFFICER? AM I FREE TO GO?
qwertyuiop924 10y ago
The sarcasm is strong with this one...
sidlls 10y ago
In fairness I haven't seen anyone make a serious comment like yours yet in this thread.
- caconym_ 10y ago
  "in b4 'we should rewrite W in X/Y/Z'" has become the new "we should rewrite W in X/Y/Z".
  - kardashian007 10y ago
    I didnt up/down vote, but rewriting in something like a performant, secure subset of Go/Rust/X and formally-proving correctness to remove many classes of errors would arguably have immense net value greater than the pain and cost of progressive/gradual rewriting migration from C to something with fewer dangerous corners and far less code to accomplish the same system behavior.
    - caconym_ 10y ago
      I don't mean to show support for either the "rewrite everything in X/Y/Z" crowd or the "C is all we need forever" crowd (or their non-straw-man equivalents). I just thought the early state of the comments in this thread was funny, is all.
SFJulie 10y ago
kernel security and later mongodb appearing randomly in a comment is like priesthood and pedophilia randomly associated. It stings of irony.
oldmanjay 10y ago
The defensive tone of this comment is unseemly. C is just a tool, and I assure you, one that feels nothing for you.
- IgorPartola 10y ago
  I love me some C. Some of the funniest projects I have worked on have been written in C. My comment was sarcastic.
  - deleted 10y ago
    [deleted]
  - qb45 10y ago
    You should have mentioned the official plan of a complete rewrite as a microkernel in message-passing dialect of Visual Basic, which was supposed to land in version 3.0. https://lkml.org/lkml/2005/3/2/247 https://lkml.org/lkml/2005/3/2/247
  - tome 10y ago
    oldmanjay did realise that ...
nine_k 10y ago
Go, unlikely. It's safer but it has other problems. Haskell is great but it's runtime makes it hard (though not impossible) to use in kernel development. Rust and ATS seem to be pretty well suited. With Rust getting more and more traction, maybe not all is lost :)
- smsm42 10y ago
  I have extremely hard time believing there can be a viable OS kernel project on Haskell. I mean, yeah, you probably can write OS kernel in Haskell, if you are determined enough. But I don't believe you can make it into a viable project. Rust - maybe, if you can get enough mindshare. Which is also a big if so far...
  - bluejekyll 10y ago
    I think Rust has the mindshare, what it needs is people actually doing it. Redox is a ground up OS, but I wonder if we shouldn't instead be taking more of an Oxidization approach where we rewrite more and more pieces of an existing OS in Rust piecemeal. This would add some overhead (programmatically not instructionwise) of a lot of context switches though between the C and the Rust code, which is to say it would be a little ugly for a while. It might be cleaner to go after a microkernel to do this though, like L4 or rumprun.
    - rbanffy 10y ago
      MkLinux was a popular environment on a portal I worked for in the late 90s. We brought dozens of Macs back into active duty as secondary workstations for the operations team.
    - smsm42 10y ago
      > I think Rust has the mindshare, what it needs is people actually doing it. That's kind of the opposite of having the mindshare, IMO :) Having the mindshare means people would be reaching for it when they need things done, not have to be dragged in, and there's a wide pool of people knowing it. I'm pretty sure you can write OS kernel in almost any language that can be compiled into runnable code, and probably if you are really determined also in those that are compiled into bytecode. As I said, it's not the main issue. Unless you are a titan of programming that can do an OS project all by yourself, or have more money than Google, you'll need random people to come to the project, pick up pieces and work on them. The question is, does Rust have pool of people wide enough so that probability of people wanting to work on your project is higher than your needs? C definitely has a huge pool. So do C++, Java, JS, Python and many other languages. Rust? I'm not sure it does so far. Maybe I'm wrong.
kardashian007 10y ago
Seriously, two things: formal verification of correctness is sorely needed and a language platform which has complete, bidirectional C interoperability in targeting both kernel- and user-land which can be gradually migrated to one compilation unit a time and has much more safety, is more succinct, has C feature parity and no/minimal runtime performance hit would be requirements for candidates to change languages, but only after impressing Linus, lieutenants and contributors of undeniable value. See also: seL4, Isabelle/Coq, Idris
- zzzcpan 10y ago
  I disagree. It is possible to put some real effort into the compiler making the same C code safe against such problems without infinitely expensive rewrites.
  - johncolanduoni 10y ago
    Tools like this for C already exist, and have existed for some time. They've failed to reach fixation, even in security-critical areas like kernels. If that is going to be the answer, then a different approach to making C safer is definitely required.
    - duneroadrunner 10y ago
      Might I suggest SaferCPlusPlus [1] as the "different approach". SaferCPlusPlus is a memory safe subset of C++. But the key is that the C++ preprocessor is now powerful enough to enable the creation of compatible safe substitutes for the unsafe C/C++ elements. (Native pointers in particular of course.) So rather than rewriting all your code, translating from traditional C/C++ to SaferCPlusPlus can be just a glorified "find and replace" exercise. (Well, maybe a little more than that, but not much.) I think solutions that don't require any code modification like Softbound and SAFEcode (and even the LLVM sanitizers) aren't popular because the resulting executables are quite slow. Whereas SaferCPlusPlus strives for minimal performance penalty. (Perhaps with some cooperation from C/C++'s formidable optimizing compilers.) (Btw, if it's not already clear, this is a shameless plug.) And not only is conversion to SaferCPlusPlus far less effort than rewriting everything in another memory safe language, it can be done completely incrementally. What language has better "bidirectional C interoperability" than C++? [1] https://github.com/duneroadrunner/SaferCPlusPlus https://github.com/duneroadrunner/SaferCPlusPlus
olalonde 10y ago
You had me until "MongoDB".
- notalaser 10y ago
  To be fair, there are a lot of places in the Linux kernel where primitive storage methods are used. In USB drivers, Vendor ID - Product ID pairs are stored in arrays. It's terrible and, most important, it doesn't scale. Being able to SELECT on a given VID would be really useful -- and it's really cool that MongoDB doesn't really impose too many constraints on the structure of your data. Look, this hasn't been a good day so far, okay?
Hydraulix989 10y ago
If anything, security vulnerabilities are precisely the kind of bugs that easily sneak by unit tests.
- drvdevd 10y ago
  I propose a new name: a dijkstranbug. Kinda like a heisenbug except specifically for unit tests.
- IgorPartola 10y ago
  Try reading my comment in the most sarcastic tone you can manage. Unit testing for security vulnerabilities has been discussed to death on HN and is generally agreed that it doesn't work. Yet, every time there is any kind of vulnerability, a comment like mine shows up, except in ernest.

deleted 10y ago

[deleted]

mperham 10y ago

AM I BEING DETAINED, OFFICER? AM I FREE TO GO?

qwertyuiop924 10y ago

The sarcasm is strong with this one...

sidlls 10y ago

In fairness I haven't seen anyone make a serious comment like yours yet in this thread.

caconym_ 10y ago
"in b4 'we should rewrite W in X/Y/Z'" has become the new "we should rewrite W in X/Y/Z".
- kardashian007 10y ago
  I didnt up/down vote, but rewriting in something like a performant, secure subset of Go/Rust/X and formally-proving correctness to remove many classes of errors would arguably have immense net value greater than the pain and cost of progressive/gradual rewriting migration from C to something with fewer dangerous corners and far less code to accomplish the same system behavior.
  - caconym_ 10y ago
    I don't mean to show support for either the "rewrite everything in X/Y/Z" crowd or the "C is all we need forever" crowd (or their non-straw-man equivalents). I just thought the early state of the comments in this thread was funny, is all.

SFJulie 10y ago

kernel security and later mongodb appearing randomly in a comment is like priesthood and pedophilia randomly associated. It stings of irony.

oldmanjay 10y ago

The defensive tone of this comment is unseemly. C is just a tool, and I assure you, one that feels nothing for you.

IgorPartola 10y ago
I love me some C. Some of the funniest projects I have worked on have been written in C. My comment was sarcastic.
- deleted 10y ago
  [deleted]
- qb45 10y ago
  You should have mentioned the official plan of a complete rewrite as a microkernel in message-passing dialect of Visual Basic, which was supposed to land in version 3.0. https://lkml.org/lkml/2005/3/2/247 https://lkml.org/lkml/2005/3/2/247
- tome 10y ago
  oldmanjay did realise that ...

nine_k 10y ago

Go, unlikely. It's safer but it has other problems. Haskell is great but it's runtime makes it hard (though not impossible) to use in kernel development. Rust and ATS seem to be pretty well suited. With Rust getting more and more traction, maybe not all is lost :)

smsm42 10y ago
I have extremely hard time believing there can be a viable OS kernel project on Haskell. I mean, yeah, you probably can write OS kernel in Haskell, if you are determined enough. But I don't believe you can make it into a viable project. Rust - maybe, if you can get enough mindshare. Which is also a big if so far...
- bluejekyll 10y ago
  I think Rust has the mindshare, what it needs is people actually doing it. Redox is a ground up OS, but I wonder if we shouldn't instead be taking more of an Oxidization approach where we rewrite more and more pieces of an existing OS in Rust piecemeal. This would add some overhead (programmatically not instructionwise) of a lot of context switches though between the C and the Rust code, which is to say it would be a little ugly for a while. It might be cleaner to go after a microkernel to do this though, like L4 or rumprun.
  - rbanffy 10y ago
    MkLinux was a popular environment on a portal I worked for in the late 90s. We brought dozens of Macs back into active duty as secondary workstations for the operations team.
  - smsm42 10y ago
    > I think Rust has the mindshare, what it needs is people actually doing it. That's kind of the opposite of having the mindshare, IMO :) Having the mindshare means people would be reaching for it when they need things done, not have to be dragged in, and there's a wide pool of people knowing it. I'm pretty sure you can write OS kernel in almost any language that can be compiled into runnable code, and probably if you are really determined also in those that are compiled into bytecode. As I said, it's not the main issue. Unless you are a titan of programming that can do an OS project all by yourself, or have more money than Google, you'll need random people to come to the project, pick up pieces and work on them. The question is, does Rust have pool of people wide enough so that probability of people wanting to work on your project is higher than your needs? C definitely has a huge pool. So do C++, Java, JS, Python and many other languages. Rust? I'm not sure it does so far. Maybe I'm wrong.

kardashian007 10y ago

Seriously, two things: formal verification of correctness is sorely needed and a language platform which has complete, bidirectional C interoperability in targeting both kernel- and user-land which can be gradually migrated to one compilation unit a time and has much more safety, is more succinct, has C feature parity and no/minimal runtime performance hit would be requirements for candidates to change languages, but only after impressing Linus, lieutenants and contributors of undeniable value. See also: seL4, Isabelle/Coq, Idris

zzzcpan 10y ago
I disagree. It is possible to put some real effort into the compiler making the same C code safe against such problems without infinitely expensive rewrites.
- johncolanduoni 10y ago
  Tools like this for C already exist, and have existed for some time. They've failed to reach fixation, even in security-critical areas like kernels. If that is going to be the answer, then a different approach to making C safer is definitely required.
  - duneroadrunner 10y ago
    Might I suggest SaferCPlusPlus [1] as the "different approach". SaferCPlusPlus is a memory safe subset of C++. But the key is that the C++ preprocessor is now powerful enough to enable the creation of compatible safe substitutes for the unsafe C/C++ elements. (Native pointers in particular of course.) So rather than rewriting all your code, translating from traditional C/C++ to SaferCPlusPlus can be just a glorified "find and replace" exercise. (Well, maybe a little more than that, but not much.) I think solutions that don't require any code modification like Softbound and SAFEcode (and even the LLVM sanitizers) aren't popular because the resulting executables are quite slow. Whereas SaferCPlusPlus strives for minimal performance penalty. (Perhaps with some cooperation from C/C++'s formidable optimizing compilers.) (Btw, if it's not already clear, this is a shameless plug.) And not only is conversion to SaferCPlusPlus far less effort than rewriting everything in another memory safe language, it can be done completely incrementally. What language has better "bidirectional C interoperability" than C++? [1] https://github.com/duneroadrunner/SaferCPlusPlus https://github.com/duneroadrunner/SaferCPlusPlus

olalonde 10y ago

You had me until "MongoDB".

notalaser 10y ago
To be fair, there are a lot of places in the Linux kernel where primitive storage methods are used. In USB drivers, Vendor ID - Product ID pairs are stored in arrays. It's terrible and, most important, it doesn't scale. Being able to SELECT on a given VID would be really useful -- and it's really cool that MongoDB doesn't really impose too many constraints on the structure of your data. Look, this hasn't been a good day so far, okay?

Hydraulix989 10y ago

If anything, security vulnerabilities are precisely the kind of bugs that easily sneak by unit tests.

drvdevd 10y ago
I propose a new name: a dijkstranbug. Kinda like a heisenbug except specifically for unit tests.
IgorPartola 10y ago
Try reading my comment in the most sarcastic tone you can manage. Unit testing for security vulnerabilities has been discussed to death on HN and is generally agreed that it doesn't work. Yet, every time there is any kind of vulnerability, a comment like mine shows up, except in ernest.