8 ms·

You are missing the forest for the trees. Grandparent is saying "replace all C with Rust" and you replied with "but look, Rust programs rely on glibc! It's unsa

by chc4 11y ago

You are missing the forest for the trees. Grandparent is saying "replace all C with Rust" and you replied with "but look, Rust programs rely on glibc! It's unsafe!" Yes, Rust programs can be affected by this. But only because they call into C at a lower level, for the libc layer. If glibc was in Rust it would provide security to all application, including ssh or curl which aren't in Rust. Also, extern "C" is for C FFI exports not calling C APIs. The world unanimously decided C FFI is the least common denominator, so its not like Rust can provide a different API with better safety hints.

ploxiln 11y ago
Or perhaps he made a more subtle point: you can't replace all C with Rust. Even if you rewrite the libc (you'll need some assembly), even if you rewrite the kernel (you'll need a lot of assembly and "unsafe"), there will still be lots of closed-source C running on undocumented components of your computer as firmware. C is just representative of computers as they really are today, for a bunch of reasons (mostly pragmatism) unrelated to the fact that some people still like C. Just as an ironic aside - C enthusiasts may even have switched to musl-libc already, and are not affected by bugs in glibc, while rust-loving people are vulnerable! Also interesting, Go has for a long time supported using its own dns resolver instead of libc, but only recently in go 1.5 uses the go dns resolver by default on unix systems.
- steveklabnik 11y ago
  We also provide builds of a MUSL-enabled rustc, if that's your thing.
- tkinom 11y ago
  Agree. "C" to OS, Kernel, Computer Language, applications is like oxygen is to life on earth. Yes, O2 causes fire from time to time, but you can't live without it.
  - cbd1984 11y ago
    Do you know of a language called "C", as opposed to C?
  - cbd1984 11y ago
    > "C" to OS There's the solution! Replace C with "C", a garbage-collected version of C! The quotes mean it's safe! /s
  - cbd1984 11y ago
    I say we should write it in "Rust", as opposed to Rust.
  - dh997 11y ago
    The analogy is wrong because most all languages are Turing complete, and therefore equivalent despite paradigm and feature differences. The main reason seL4 was written in Haskell and again in C was to cross-verify behavior. C might be legacy ubiquitous, however it doesn't have to be the last word in shared library development by any means. Any language which has a toolchain which produce flat binaries or use link scripts to specify sections can potentially be used for kernel and os dev. Bonus points for a toolchain which can compile itself. There are kernels written entirely in Rust with some assembly glue. Others are writing production embedded domain-specific OSes in Haskell, OCaml, etc. for real, mission-critical systems right now and have been doing so for the last 5-10 years. C inherently or inadvertently leads to giant codebases and subtle bugs when used too liberally, as opposed to higher-level, statically-compiled languages like Haskell and others. The main issue with legacy code is how we choose to either keep investing effort in putting fingers into the levees or try something new in an incremental fashion. PS: I would like to see Go get with it and support non-usermode, self-hosted and embedded development without including a giant, hard-to-port runtime in everything.
    - cyphar 11y ago
      > The main reason seL4 was written in Haskell and again in C was to cross-verify behavior. seL4 was modeled in Haskell, then written in C. Then they used tools to verify that the Haskell models matched the C code.
- mkj 11y ago
  musl isn't without resolver bugs either. http://www.openwall.com/lists/oss-security/2015/03/30/3 http://www.openwall.com/lists/oss-security/2015/03/30/3
- viraptor 11y ago
  Are you arguing that since we can't replace everything with safe code, we shouldn't replace most of it? Security is not a binary state. Even taking firmware into account, if you compare the number of CVEs affecting "normal code" and firmware, the choice is trivial.
  - ptaipale 11y ago
    > Are you arguing that since we can't replace everything with safe code, we shouldn't replace most of it? Well, yes, the effort to replace even a small part of current code base with something perceived as "safe code" is huge. The re-factoring effort is so great that there is no doubt a significant number of new seurity problems wouldn't be created. They would of course be different kind of problems. Not indexing errors, perhaps, but something we don't even know about. And justifiying this very large cost is not so easy.
- agumonkey 11y ago
  Good point, we shouldn't be dogmatic but pragmatic. But there's a fallacy conveyed by seeing C idioms as the only low level ones.
autoreleasepool 11y ago
Do some low level Rust programming and then do some low level C programming. It's hardly any safer, because it can't be safe at such a low level without a performance penalty. In the capitalist reality we live in, that is a cost no one will pay. You're talking about the forrest - while we're talking about how making trees from scratch is difficult and messed up no matter how you go about it. At some point, you have to talk to the computer directly (aka "unsafely"). Things like bounds checking, garbage collection, and other runtime utilities sound like great ideas until they translate to significant monetary costs each month. Not everything is as trivial as writing GUI glue code in a nice comfy language with a magical framework. Although, most of it is.
- andrewjl 11y ago
  I'd really like to see a good write up on a project that's trying to tackle this problem on the levels below C. (Assembly or even hardware level.)
  - cbd1984 11y ago
    The x86 ISA already has bounds-checking opcodes which can be used to ensure array accesses don't go off the deep end.
- steveklabnik 11y ago
  > it can't be safe at that low level without a performance penalty. Many of Rust's safety guarantees come from compile-time checks that then do not have any runtime penalty. Yes, sometimes you still need unsafe, but even then, it's a superset, not a subset: a lot of safety checks still happen inside an unsafe block. That said, I do think that building a libc in Rust would take a significant investment and I'm not sure who's going to even attempt it, if anyone.
  - acconsta 11y ago
    >Many of Rust's safety guarantees come from compile-time checks that then do not have any runtime penalty. But not bounds checks, which are unfortunately what you need with respect to buffer overflows.

by chc4 11y ago

ploxiln 11y ago

Or perhaps he made a more subtle point: you can't replace all C with Rust. Even if you rewrite the libc (you'll need some assembly), even if you rewrite the kernel (you'll need a lot of assembly and "unsafe"), there will still be lots of closed-source C running on undocumented components of your computer as firmware. C is just representative of computers as they really are today, for a bunch of reasons (mostly pragmatism) unrelated to the fact that some people still like C. Just as an ironic aside - C enthusiasts may even have switched to musl-libc already, and are not affected by bugs in glibc, while rust-loving people are vulnerable! Also interesting, Go has for a long time supported using its own dns resolver instead of libc, but only recently in go 1.5 uses the go dns resolver by default on unix systems.

steveklabnik 11y ago
We also provide builds of a MUSL-enabled rustc, if that's your thing.
tkinom 11y ago
Agree. "C" to OS, Kernel, Computer Language, applications is like oxygen is to life on earth. Yes, O2 causes fire from time to time, but you can't live without it.
- cbd1984 11y ago
  Do you know of a language called "C", as opposed to C?
- cbd1984 11y ago
  > "C" to OS There's the solution! Replace C with "C", a garbage-collected version of C! The quotes mean it's safe! /s
- cbd1984 11y ago
  I say we should write it in "Rust", as opposed to Rust.
- dh997 11y ago
  The analogy is wrong because most all languages are Turing complete, and therefore equivalent despite paradigm and feature differences. The main reason seL4 was written in Haskell and again in C was to cross-verify behavior. C might be legacy ubiquitous, however it doesn't have to be the last word in shared library development by any means. Any language which has a toolchain which produce flat binaries or use link scripts to specify sections can potentially be used for kernel and os dev. Bonus points for a toolchain which can compile itself. There are kernels written entirely in Rust with some assembly glue. Others are writing production embedded domain-specific OSes in Haskell, OCaml, etc. for real, mission-critical systems right now and have been doing so for the last 5-10 years. C inherently or inadvertently leads to giant codebases and subtle bugs when used too liberally, as opposed to higher-level, statically-compiled languages like Haskell and others. The main issue with legacy code is how we choose to either keep investing effort in putting fingers into the levees or try something new in an incremental fashion. PS: I would like to see Go get with it and support non-usermode, self-hosted and embedded development without including a giant, hard-to-port runtime in everything.
  - cyphar 11y ago
    > The main reason seL4 was written in Haskell and again in C was to cross-verify behavior. seL4 was modeled in Haskell, then written in C. Then they used tools to verify that the Haskell models matched the C code.
mkj 11y ago
musl isn't without resolver bugs either. http://www.openwall.com/lists/oss-security/2015/03/30/3 http://www.openwall.com/lists/oss-security/2015/03/30/3
viraptor 11y ago
Are you arguing that since we can't replace everything with safe code, we shouldn't replace most of it? Security is not a binary state. Even taking firmware into account, if you compare the number of CVEs affecting "normal code" and firmware, the choice is trivial.
- ptaipale 11y ago
  > Are you arguing that since we can't replace everything with safe code, we shouldn't replace most of it? Well, yes, the effort to replace even a small part of current code base with something perceived as "safe code" is huge. The re-factoring effort is so great that there is no doubt a significant number of new seurity problems wouldn't be created. They would of course be different kind of problems. Not indexing errors, perhaps, but something we don't even know about. And justifiying this very large cost is not so easy.
agumonkey 11y ago
Good point, we shouldn't be dogmatic but pragmatic. But there's a fallacy conveyed by seeing C idioms as the only low level ones.

autoreleasepool 11y ago

Do some low level Rust programming and then do some low level C programming. It's hardly any safer, because it can't be safe at such a low level without a performance penalty. In the capitalist reality we live in, that is a cost no one will pay. You're talking about the forrest - while we're talking about how making trees from scratch is difficult and messed up no matter how you go about it. At some point, you have to talk to the computer directly (aka "unsafely"). Things like bounds checking, garbage collection, and other runtime utilities sound like great ideas until they translate to significant monetary costs each month. Not everything is as trivial as writing GUI glue code in a nice comfy language with a magical framework. Although, most of it is.

andrewjl 11y ago
I'd really like to see a good write up on a project that's trying to tackle this problem on the levels below C. (Assembly or even hardware level.)
- cbd1984 11y ago
  The x86 ISA already has bounds-checking opcodes which can be used to ensure array accesses don't go off the deep end.
steveklabnik 11y ago
> it can't be safe at that low level without a performance penalty. Many of Rust's safety guarantees come from compile-time checks that then do not have any runtime penalty. Yes, sometimes you still need unsafe, but even then, it's a superset, not a subset: a lot of safety checks still happen inside an unsafe block. That said, I do think that building a libc in Rust would take a significant investment and I'm not sure who's going to even attempt it, if anyone.
- acconsta 11y ago
  >Many of Rust's safety guarantees come from compile-time checks that then do not have any runtime penalty. But not bounds checks, which are unfortunately what you need with respect to buffer overflows.