6 ms·

Are there any big efforts to rewrite glibc in something like rust? ... Is that a thing that is even possible? An in-place replacement library for dynamic or sta

• lmm 11y ago
  It would be a wasted effort. Anything that's using glibc (directly) is written in C and therefore inherently unsafe. There are only two kinds of programs written in C: those that need to do unsafe things and those whose developers don't care about safety. Better to look to building systems that don't need to run any C code (see the recent fuss around unikernels).
  • qb45 11y ago
    > Anything that's using glibc (directly) is written in C ... and together with stuff using glibc (indirectly) constitutes 99.99% of your software. How much software/languages implement their own DNS resolver instead of just calling libc? How about syscall wrappers?
    • lmm 11y ago
      The JVM looks to have its own implementation. I imagine .net would be the same. There's ocaml-dns for unikernel-deployed OCaml. A managed language generally doesn't give you direct access to syscalls at all. In rust you can perform them without having to go via C.
      • gpderetta 11y ago
        Note that DNS lookup doesn't require any syscall other than normal socket i/o, which is available on any non toy language. One possible reason why java might implements its own name resolution is because it wants to do async name resolution which is not possible (at least portably) via getaddrinfo and friends.
        • spc476 11y ago
          Yes, but you still need to encode the questions and decode the answers. Existing libraries that do this are pretty dismal. (Dismal enough that I ended up writing my own DNS encoding/decoding library (https://github.com/spc476/SPCDNS https://github.com/spc476/SPCDNS) with the aim of being easy to use as well as safe. It assumes nothing about the incoming packet and does extensive validation (enough that it found bugs in other DNS libraries). It also avoids dynamic memory allocations. It's used at work in two projects that get heavy use (millions of DNS queries a day) and so far has performed without incident, so well written C code is possible.)
      • zwetan 11y ago
        With Redtamarin (based on AVM2), there is a native library which sole purpose is to give direct access to C and other syscalls. For ex with getaddrinfo: https://gist.github.com/zwetan/0c047d36542cc6979652 https://gist.github.com/zwetan/0c047d36542cc6979652 I know because I did it on purpose, even if it managed code written in AS3 you don't want to reinvent getaddrinfo, you want to reuse it "as is" as much as possible.
  • fpoling 11y ago
    The problem is not C as one can compile C into NaCl or asm.js and get memory safe code. One can also use a number of static checkers. The real problem is that even this is not done in cases when using C is a must due to project nature.
    • gpderetta 11y ago
      Compiling to NaCl or asm.js doesn't make an arbitrary C program memory safe. It "merely" prevents any memory safety failure to affect anything outside the container. This is different from, for example, java bytecode which is verified and guaranteed to be memory safe. This is not a mere technicality: an heartbleed vulnerable version of openssl compiled on top of asm.js or NaCl would still leak secret information. edit: typo
      • fpoling 11y ago
        Both asm.js and NaCl guarantee execution stack integrity and allow jumps only at predefined targets in code making exploiting bugs like this highly problematic. Data-only exploits are hard and in asm.js case they are father limited as access outside of the memory leads to program termination. On the other hand memory safety does not prevent bugs like Heartbleed or resent OpenSSH key leak. As the underling issue is related to broken reuse of a cached buffer, such code can be written in Java or even Rust just as well.
        • gpderetta 11y ago
          Sure, but these are (very effective) mitigation techniques, but still do not guarantee memory safety. You are right that Heartbleed is not a memory safety issue, I should have been more careful. I just wanted an example of an exploit that doesn't need to escape the process boundary to cause damage.
• 102030485868 11y ago
  I'm not sure how likely that'll be. It's definitely possible, but I think there are going to be a few hurdles. The main one being, symbol versioning. This is important if you export multiple symbols for a function, that is, have a program that depends on a specific implementation of a function. That could mean you depend on different versions of the same library ("functionname@@VERSION_1, functionname@@VERSION_2"), or completely different implementations of a function ("functionname@@IMPL_X_VER_1", "functionname@@IMPL_Y_VER_2"). Wait a second. That seems like a strange feature to want, right? Well. It's particularly useful for runtime library fun stuff. LD_PRELOAD in a library that magically changes the implementation of function. A cool example of this is of preeny[1], a collection of libraries to help with debugging. Additionally, it's useful for replacing libraries that would depend on C implementations without having to recompile them, though some preloading magic at runtime may be required. This is only the thing, for me at least, that's blocking for making Rust system libraries. Now, any sane person may say, "Cargo will take care of versions and stuff", and that's true. Sadly, that's not the case if you ever want to use those nice and safe Rust libraries from C though. Though, I may be completely wrong about the state of symbol versioning in Rust. I simply ran 'nm -g libopenssl.so' on sfackler's rust-openssl project and failed to see any @@<version> in the output -- that is specifically being exported, and not re-exported, by libopenssl. There may be better libraries to use, but eh. I could be completely wrong on this though. I've been mainly going off of what I read here[2], and here[3] (alternatively, for a more in-depth version, try here[4]). TL;DR: symbol versioning may not be a thing. Disclaimer: I've had to use symbol versioning pretty heavily, so it's important to me. I could also be completely wrong about Rust not having it. [1]: https://github.com/zardus/preeny https://github.com/zardus/preeny [2]: https://gcc.gnu.org/wiki/SymbolVersioning https://gcc.gnu.org/wiki/SymbolVersioning [3]: https://www.akkadia.org/drepper/symbol-versioning https://www.akkadia.org/drepper/symbol-versioning [4]: https://www.akkadia.org/drepper/dsohowto.pdf https://www.akkadia.org/drepper/dsohowto.pdf
  • kimundi 11y ago
    The default name mangling of Rust library symbols is already kinda versioned because it includes a hash of the library, so two different versions of a library can coexist at the same time. As far explicitly using the symbol versioning scheme you mentioned, you can do it with an attribute today: https://play.rust-lang.org/?gist=92be155702d53c6411b2&version=stable https://play.rust-lang.org/?gist=92be155702d53c6411b2&versio... (Disclaimer: I haven't actually compiled this as a dynamic library and checked, but its what that attribute is for, and the names seem to be used verbatim in the ASM output)
• autoreleasepool 11y ago
  I'm not trying to be rude, but I'm sorry... Are you seriously suggesting that rewriting an implementation of the C standard library in a language that isn't C is something that makes any bit of sense? I think you have a fundemental understanding of the roll the C-standard library plays in the C language. Not to mention UNIX in general. Maybe you're suggesting we need an OS based in Rust instead of C (which is more reasonable), but in that case why wouldn't you use Rust's standard library as the backbone of that system? Let me put it this way, if the GNU/Linux C standard library gets rewritten in Rust or Idris (sigh... seriously?) I will switch to Windows 10 with default settings for the rest of my life. I would rather have the NSA log my every key stroke than participate in a community where that is considered a good idea.
  • arielb1 11y ago
    Rust can have the same ABI as C - rewriting NSS in Rust should not pose ABI problems.
    • autoreleasepool 11y ago
      It's still completely pointless. How would mmap be any different if it was implemented in Rust rather than in C? You need unsafe to implement it! The safety mechanisms are practically useless at such a low level. Wrap existing C with safe Rust, not the other way around! We don't rewrite unsafe C code in Unsafe Rust so that it can be called from all the unsafe C code in UNIX. Such a translation is so pointless and error prone. I can't even believe I'm the one being called backwards here.
      • dbaupp 11y ago
        > How would mmap be any different if it was implemented in Rust rather than in C? You need unsafe to implement it! The safety mechanisms are practically useless at such a low level. They're definitely not. The power of Rust is not avoiding all `unsafe` ever, but wrapping that unsafe into finite-scope, safe wrappers. Something like mmap would presumably interface with the OS's internal memory management routines, which would definitely have to have `unsafe` somewhere since they're hitting the hardware, but it seems very reasonable for the amount of unsafe exposed to much reduced (possibly even to zero). See, for instance, http://os.phil-opp.com/modifying-page-tables.html http://os.phil-opp.com/modifying-page-tables.html . Basically, as soon as you're above the absolute raw hardware level, you can start introducing extra help to reduce unsafety/catch bugs. In any case, code inside `unsafe` still benefits from all the conventional Rust checks, e.g. iterating over a slice won't go out of bounds due to a typo in the loop even inside `unsafe`, nor will references accidentally become dangling. (Of course, the `unsafe` block may do something explicitly that causes either of these problems, but this exact same risk is pervasive in all C code, rather than just around explicitly marked areas.) > Wrap existing C with safe Rust, not the other way around! We don't rewrite unsafe C code in Unsafe Rust so that it can be called from all the unsafe C code in UNIX. Such a translation is so pointless and error prone. Note that this is exactly what is done now, the features of Rust for making safe interfaces makes Rust often a far nicer way to use C interfaces than C itself, without overhead (IMO, of course). See http://blog.rust-lang.org/2015/04/24/Rust-Once-Run-Everywhere.html#safe-abstractions http://blog.rust-lang.org/2015/04/24/Rust-Once-Run-Everywher... , for example. Of course, zero-overhead Rust is only as safe as the C code it wraps, it can't (in general) protect against the C code not correctly implementing its stated contract(s).