26 ms·

Writing into Uninitialized Buffers in Rust

129 points by luu 1y ago

90s_dev 1y ago
Write into uninit'd buffers was one of the pain points of Rust for the creator of the new open source "edit" program for Windows[1]. I wonder what he thinks of this article. > Another thing is the difficulty of using uninitialized data in Rust. I do understand that this involves an attribute in clang which can then perform quite drastic optimizations based on it, but this makes my life as a programmer kind of difficult at times. When it comes to `MaybeUninit`, or the previous `mem::uninit()`, I feel like the complexity of compiler engineering is leaking into the programming language itself and I'd like to be shielded from that if possible. At the end of the day, what I'd love to do is declare an array in Rust, assign it no value, `read()` into it, and magically reading from said array is safe. That's roughly how it works in C, and I know that it's also UB there if you do it wrong, but one thing is different: It doesn't really ever occupy my mind as a problem. In Rust it does. [https://news.ycombinator.com/item?id=44036021 https://news.ycombinator.com/item?id=44036021]
- electrograv 1y ago
  > That's roughly how it works in C, and I know that it's also UB there if you do it wrong, but one thing is different: It doesn't really ever occupy my mind as a problem. In Rust it does. UB doesn’t occupy the author’s mind when writing C, when it really should. This kind of lazy attitude to memory safety is precisely why so much C code is notoriously riddled with memory bugs and security vulnerabilities.
  - mk12 1y ago
    There is an important difference for this case though. It C it’s fine to have pointers into uninitialized memory as you as you don’t read them until after initializing. You can write through those pointers the same way you always do. In Rust it’s UB as soon as you “produce” an invalid value, which includes references to uninitialized memory. Everything uses references in Rust but when dealing with uninitialized memory you have to scrupulously avoid them, and instead write through raw pointers. This means you can’t reuse any code that writes through &mut. Also, the rules change over time. At one point I had unsafe code that had a Vec of uninitialized elements, which was ok because I never produced a reference to any element until after I had written them (through raw pointers). But they later changed the Vec docs to say that’s UB, I guess because they want to reserve the right to use references even if you never call a method that returns a reference.
    - Arnavion 1y ago
      This stopped being much of a problem when MaybeUninit was stabilized. Now you can stick to using &MaybeUninit<T> / &mut MaybeUninit<T> instead of needing to juggle *T / *mut T and carefully track converting that to &T / &mut T only when it's known to be initialized, and you can't accidentally use a MaybeUninit<T> where you meant to use a T because the types are different. It's not as painless as it could be though, because many of the MaybeUninit<T> -> T conversion fns are unstable. Eg the code in TFA needs `&mut [MaybeUninit<T>] -> &mut [T]` but `[T]::assume_init_mut()` is unstable. But reimplementing them is just a matter of copying the libstd impl, that in turn is usually just a straightforward reinterpret-cast one-liner.
    - nemothekid 1y ago
      Bizarre. I think I've been writing broken Rust code for a couple years. If I understand you correctly something like: let mut data = Vec::with_capacity(sz); unsafe { data.set_len(sz) }; buf.copy_to_slice(data.as_mut_slice()); is UB?
      - vgatherps 1y ago
        Yes, this is the case that I ran into as well. You have to zero memory before reading and/or have some crazy combination of tracking what’s uninitialized capacity or initialized len, I think the rust stdlib write trait for &mut Vec got butchered over this concern. It’s strictly more complicated and slower than the obvious thing to do and only exists to satisfy the abstract machine.
        Arnavion 1y ago
        No. The correct way to write that code is to use .spare_capacity_mut() to get a &mut [MaybeUninit<T>], then write your Ts into that using .write_copy_of_slice(), then .set_len(). And that will not be any slower (though obviously more complicated) than the original incorrect code.
        vgatherps 1y ago
  - o11c 1y ago
    The reason this particular UB doesn't need mindspace for C programmers is because it's not even meaningful to do anything with the parts of the buffer beyond the written length. Most other UBs related to datums that you think you can do something with.
  - usefulcat 1y ago
    I suspect that the main reason it doesn't really occupy the author's mind is that even though it's possible to misuse read(), it's really not that hard to actually use it safely. It sounds like the more difficult problem here has to do with explaining to the compiler that read() is not being used unsafely.
  - lhecker 1y ago
    What I meant is that if I write a UTF8 --> UTF16 conversion function for my editor in C I can write size_t convert(state_t* state, const void* inp, void* out) This function now works with both initialized and uninitialized data in practice. It also is transparent over whether the output buffer is an `u8` (a byte buffer to write it out into a `File`) or `u16` (a buffer for then using the UTF16). I've never had to think about whether this doesn't work (in this particular context; let's ignore any alignment concerns for writes into `out` in this example) and I don't recall running into any issues writing such code in a long long time. If I write the equivalent code in Rust I may write fn convert(&mut self, inp: &[u8], out: &mut [MaybeUninit<u8>]) -> usize The problem is now obvious to me, but at least my intention is clear: "Come here! Give me your uninitialized arrays! I don't care!". But this is not the end of the problem, because writing this code is theoretically unsafe. If you have a `[u8]` slice for `out` you have to convert it to `[MaybeUninit<u8>]`, but then the function could theoretically write uninitialized data and that's UB isn't it? So now I have to think about this problem and write this instead: fn convert(&mut self, inp: &[u8], out: &mut [u8]) -> usize ...and that will also be unsafe, because now I have to convert my actual `[MaybeUninit<u8>]` buffer (for file writes) to `[u8]` for calls to this API. Long story short, this is a problem that occupies my mind when writing in Rust, but not in C. That doesn't mean that C's many unsafeties don't worry me, it just means that this _particular_ problem type described above doesn't come up as an issue in C code that I write. Edit: Also, what usefulcat said.
    - ninkendo 1y ago
      Why wouldn’t you accept a &mut [MaybeUninit<T>] and return a &mut [u8], hiding the unsafe bits that transmute the underlying reference? Something like: fn convert<'i, 'o>(inp: &'i [u8], buf: &'o mut MaybeUninit<u8>) -> &'o mut [u8] (Honest question, actually… because the above may be impossible to write and I’m on my phone and can’t try it.) Edit: it works: https://play.rust-lang.org/?version=stable&mode=debug&edition=2024&gist=29cb6251fbd9626910cf4d7306394562 https://play.rust-lang.org/?version=stable&mode=debug&editio...
      - lhecker 1y ago
        That's a fair workaround for my specific example. But I believe it's possible to contrive a different example where such a solution would not be possible. Put differently, I only tried to convey the overall idea of what I think is a shortcoming in Rust at the moment. Edit: Also, I believe your code would fail my second section, as the `convert` function would have difficulty accepting a `[u8]` slice. Converting `[u8]` to `[MaybeUninit<u8>]` is not safe per se.
- ii41 1y ago
  I think this solves his problem. He said he wants a read function that turns the unsafe buffer into a safe buffer, and this API does that. IIRC it's not that hard to convince the compiler to give you a safe buffer from a MaybeUninit. However, this type has really lengthy docs and makes you question everything you do with it. Thinking through all this is painful but it's not like you don't have to it with C.
- jcranmer 1y ago
  The basic problem with uninitialized buffers is that they effectively require write-only references to exist, and Rust's type system doesn't have (and doesn't easily support) write-only references, only read-only and read-write. MaybeUninit is a partial solution to the problem, but since it's a library solution and not a language solution, it suffers from a lack of integration with the language, e.g., getting MaybeUninit fields from a MaybeUninit struct is challenging. And the most aggravating part of all of this is that the most common use case for uninitialized memory (the scenario being talked about both in the article here and the discussion you quote) is actually pretty easy to have a reasonable, safe abstraction for, so the fact that the current options requires both use of unsafe code and also potentially faulty duplication of value calculations doesn't make for a fun experience. (Also, the I/O traits predate MaybeUninit, which means the most common place to want to work with uninitialized memory is one where you can't do it properly.)
  - 90s_dev 1y ago
    Then is the solution to have write-only be the default for muts, so that they start out write-only at least, but can also be made to be read-write either (a) in given circumstances of creation, or (b) after certain operations on them, or (c) if created by certain APIs?
- lhecker 1y ago
  Abstracting away the `assume_init` is a great idea! I think I could use something like that for the editor. The only concern I have is that the `read` function is templated on the parameter type. I'd ideally _really_ prefer it if I didn't need two copies of the same function to switch over `[u8]` and `[MaybeUninit<u8>]` due to different return types. [^1] I guess the approach could be tuned to avoid this? Personally, I also like the simpler approach overall, compared to the `BorrowedBuf` trait, for the same reasons outlined in the article. While this possibly solves parts of pain points that I had, what I meant to write is that in an ideal world I could write Rust while mostly not thinking about this issue much, if at all. Even with this approach, I'd still need to decide whether my API needs to take a `[u8]` or a `Buffer`, just in the mere off-chance that a caller may want to pass an uninitialized array further up in the call chain. This then requires making the call path generic for the buffer parameter which may end up duplicating any of the functions along the path, even though that's not really my intention by marking it as `Buffer`. I think if there was a way to modify Rust so we can boldly state in writing "You may cast a `[MaybeUninit<T>]` into a `[T]` and pass it into a call _if_ you're absolutely certain that nothing reads from the slice", it would already go a long way. It may not make this more comfortable yet, but it would definitely take off a large part of my worries when writing such unsafe casts. That's basically what I meant with "occupy my mind": It's not that I wouldn't think about it at all, rather it just wouldn't be a larger concern for me anymore, for code where I know for sure that this requirement is fulfilled (i.e. similar to how I know it when writing equivalent C code). Edit: jcranmer's suggestion of write-only references would solve this, I think? https://news.ycombinator.com/item?id=44048450 https://news.ycombinator.com/item?id=44048450 [^1]: This is of course not a problem for a simple `read` syscall, but may be an issue for more complex functions, e.g. the UTF8 <> UTF16 converter API I suggested elsewhere in this thread, particularly if it's accelerated, the way simdutf is.
vgatherps 1y ago
I wish that there was a useful “freeze” intrinsic exposed, even if only for primitive types and not for generic user types, where the values of the frozen region become unspecified instead of undefined. I believe llvm has one now? Iirc the work on safe transmute also involves a sort of “any bit pattern” trait? I’ve also dealt with pain implementing similar interfaces in Rust, and it really feels like you end up jumping through a ton of hoops (and in some of my cases, hurting performance) all to satisfy the abstract machine, at no benefit to programmer or application. It’s really a case where the abstract machine cart is leading the horse
- CJefferson 1y ago
  I agree, I'd go further and say I wonder why primitive types aren't "frozen" by default. I totally understand not wanting to promise things get zeroed, but I don't really understand why full UB, instead of just "they have whatever value is initially in memory / the register / the compiler chose" is so much better. Has anyone ever done a performance comparison between UB and freezing I wonder? I can't find one.
  - wrs 1y ago
    That assumes the compiler reserves one continuous place for the value, which isn’t always true (hardly ever true in the case of registers). If the compiler is required to make all code paths result in the same uninitialized value, that can limit code generation options, which might reduce performance (and performance is the whole reason to use uninitialized values!). Also, an uninitialized value might be in a memory page that gets reclaimed and then mapped in again, in which case (because it hasn’t been written to) the OS doesn’t guarantee it will have the same value the second time. There was recently a bug discovered in one of the few algorithms that uses uninitialized values, because of this effect.
    - CJefferson 1y ago
      But, I wonder how much it would reduce performance, if we only have to pick a value the first time the memory is read? I would imagine there isn't that many cases where we are reading uninitalised memory and counting on that reading not saving a value. It would happen when reading in 8-byte blocks for alignment, but does it happen that much elsewhere?
leoh 1y ago
Just dropping to C for a smallish segment of a rust program kind of makes sense if you want to eke out performance here, no?
- bjackman 1y ago
  You can always just use unsafe. This is about how to allow code to do this without unsafe blocks.
- Arnavion 1y ago
  It does, though even for a small segment you end up needing a lot of boilerplate - a dependency on the cc crate, a build.rs that invokes the cc crate, extern declarations to tell the Rust caller about the C function, potentially some bindgen if your small segment is not so small ... and you still end up having to do some amount of thunking between & / * / MaybeUninit because of that anyway. So if there is a "pure Rust" way to do it with `unsafe`, writing that is often easier. The pure Rust impl also has the advantage that you can validate it with Miri, unlike the C impl case because Miri cannot emulate arbitrary C code.
  - leoh 1y ago
    This is a good point and perhaps points to an opportunity with cargo, macros, the rust language, or other aspects of the build system.
- IshKebab 1y ago
  Yeah but the C toolchain is a huge pain, and makes things like cross-compiling and compiling to WASM harder. It's really nice if you can keep your program pure Rust. Go has similar characteristics.
  - nottorp 1y ago
    > compiling to WASM I thought Rust was supposed to be a systems language?
    - 1y ago
briansm 1y ago
Pardon my ignorance, but I thought the whole point of Rust was to be a 'safe' modern alternative to C, so all new buffers would be zero'd at a neglible-these-days cost. Why is rust half-assing this?
- vlovich123 1y ago
  It’s not. That is the case. But in cases where “negligible-these-days” isn’t quite negligible enough, this still matters and unsafe + MaybeUninit is the escape hatch to accomplish it.
  - Arnavion 1y ago
    Also not every type has a valid "all zeroes" value in the first place.
  - briansm 1y ago
    Yuck. In my mind, 'using C and not using Rust in the first place' is the escape hatch and Rust shouldn't even go there. Jeez, what a mess.
    - JoshTriplett 1y ago
      This is why we're spending substantial energy building better abstractions that don't require you to write any unsafe code.
    - vlovich123 1y ago
      Rust provides all the safety guarantees of managed languages with none of the performance drawbacks. It’s precisely intended to replace C/C++ because the unsafe parts of Rust are used very sparingly and result in significantly fewer bugs and security vulnerabilities. Safe abstractions for dealing with uninitialized memory efficiently are important in very niche scenarios to get optimal code out of the compiler and for reducing the ability to make a mistake when writing such code. Reaching for C to do this is an emotional overreaction instead of calmly dealing with a small corner case that already has workarounds even if it does involve using unsafe
sqrt_1 1y ago
Related to unspecified vs undefined. I recall some C code was trying to be tricky and read from just allocated memory. Something like: int* ptr = malloc(size); if(ptr[offset] == 0) { } The code was assuming that the value in an allocated buffer did not change. However, it was pointed out in review that it could change with these steps: 1) The malloc allocates from a new memory page. This page is often not mapped to a physical page until written to. 2) The reads just return the default (often 0 value) as the page is not mapped. 3) Another allocation is made that is written to the same page. This maps the page to physical memory which then changes the value of the original allocation.
- Arnavion 1y ago
  A read from an unmapped page producing a different value than reading from that same page after it's mapped is an OS bug (*). If this was an already allocated page that had something written to it, reading from it would page it back in and then produce the actual content. If this was a new page and the OS contract was to provide zeroed pages, both the read before it was mapped and the read after it was mapped would produce zero. What could happen is that the UB in that code could result in it being compiled in a way that makes the comparison non-deterministic. (*): ... or alternatively, we're not talking about regular userspace program but a higher privilege layer that is doing direct unpaged access, but I assume that's not the case since you're talking about malloc.
  - sqrt_1 1y ago
    It was from C++con 2016 - Facebook take on small strings https://www.youtube.com/watch?v=kPR8h4-qZdk&t=1343s https://www.youtube.com/watch?v=kPR8h4-qZdk&t=1343s I believe it is about a page that was conditionally returned to the kernel.
    - Arnavion 1y ago
      The speaker was mistaken / misspoke. The closest thing to "conditionally returned to the kernel" is if the page had been given to madvise(MADV_FREE), but that would still not have the behavior they're talking about. Reading and writing would still produce the same content, either the original page content because the kernel hasn't released the page yet, or zero because the kernel has already released the page. Even if the order of operations is read -> kernel frees -> write, then that still doesn't match their story, because the read will produce the original page content, not zero. That said, the code they're talking about is different from yours in that their code is specifically doing an out-of-bounds read. (They said "If you happen to allocate a string that's 128 bytes, and malloc happens to return an address to you that's 128 bytes away from the end of the page, you'll write the 128 bytes and the null terminator will be the first byte on the next page. So they're very clearly talking about the \0 being outside the allocation.) So it is absolutely possible to have this setup: the string's allocation happens to be followed by a different allocation that is currently 0 -> the `data[size()] != '\0'` check is performed and succeeds -> `data` is returned to the caller -> whoever owns that following allocation writes a non-zero value to the first byte -> whoever called `c_str()` will now run off the end of the 128B string. This doesn't have anything to do with pages; it can happen within the bounds of a single page. It is also such an obvious out-of-bounds bug that it boggles my mind that it passed any sort of code review and required some sort of graybeard to point out.
mleonhard 1y ago
> without doing anything hugely inefficient, such as initializing the full buffer Is this so inefficient? If your code is very sensitive to IO throughput, then it seems preferable to re-use buffers and pay the initialization once at startup. Some years ago, I needed a buffer like this and one didn't exist, so I wrote one: https://crates.io/crates/fixed-buffer https://crates.io/crates/fixed-buffer . I like that it's a plain struct with no type parameters.
- MaulingMonkey 1y ago
  > Is this so inefficient? It can be. If you have large buffers (tuned for throughput) that end up fulfilling lots of small requests for whatever reason, for example. And there's always the occasional article when someone rediscovers that replacing malloc + memset with calloc can have massive performance savings thanks to zeroing by the OS only occuring on first page fault (if it ever occurs), instead of an O(N) operation on the whole buffer up front. Which, if in the wrong loop, can quickly balloon from O(N) to O(scary). https://github.com/PSeitz/lz4_flex/issues/147 https://github.com/PSeitz/lz4_flex/issues/147 https://github.com/rust-lang/rust/issues/117545 https://github.com/rust-lang/rust/issues/117545 If I'm reading that log-log plot right, that looks like a significantly worse than 100x slowdown on 1GB data sets. Avoiding init isn't the only solution, of course, but it was a solution. > then it seems preferable to re-use buffers Buffer reuse may be an option, but in code with complicated buffer ownership (e.g. transfering between threads, with the thread of origination not necessarily sticking around, etc.), one of the sanest methods of re-use may be to return said buffer to the allocator, or even OS. > and pay the initialization once at startup. Possibly a great option for long lived processes, possibly a terrible one for something you spawn via xargs.
pornel 1y ago
Couple of things that are commonly misunderstood/unappreciated about this: • Uninitialized bytes are not just some garbage random values, they're a safety risk. Heartbleed merely exposed unitialized buffers. Uninit buffers can contain secrets, keys, and pointers that help defeat ASLR and other mitigations. As usual, Rust sets the bar higher than "just be careful not to have this bug", and therefore the safe Rust subset requires making uninit impossible to read. • Rust-the-language can already use uninitialized buffers efficiently. The main issue here is that the Rust standard library doesn't have APIs for I/O using custom uninitialized buffers (only for the built-in Vec, in a limited way). These are just musings how to design APIs for custom buffers to make them the most useful, ergonomic, and interoperable. It's a debate, because it could be done in several ways, with or without additions to the language.
- ajross 1y ago
  > Uninitialized bytes are not just some garbage random values, they're a safety risk. Only when read. Writing to "uninitialized" memory[1] and reading it back is provably secure[2], but doesn't work in safe Rust as it stands. The linked article is a proposal to address that via some extra complexity that I guess sounds worth it. [1] e.g. using it as the target of a read() syscall [2] Because it's obviously isomorphic to "initialization"
  - pornel 1y ago
    Obviously, initialized memory isn't an uninitialized memory any more. There are fun edge cases here. Writing to memory through `&mut T` makes it initialized for T, but its padding bytes become de-initialized (that's because the write can be a memcpy that also copies the padding bytes from a source that never initialized them).
    - lilyball 1y ago
      Note that if you have a `&mut T` then the memory must already be initialized for T, so writing to that pointer doesn't initialize anything new (although as you say it can deinitialize bytes, but that only matters if you use transmute or pointer casting to get access to those padding bytes somehow).
az09mugen 1y ago
With so much unsafe, it makes me think of that fun experimental usage of rust : https://github.com/tsoding/Crust https://github.com/tsoding/Crust

129 points by luu 1y ago

Write into uninit'd buffers was one of the pain points of Rust for the creator of the new open source "edit" program for Windows[1]. I wonder what he thinks of this article. > Another thing is the difficulty of using uninitialized data in Rust. I do understand that this involves an attribute in clang which can then perform quite drastic optimizations based on it, but this makes my life as a programmer kind of difficult at times. When it comes to `MaybeUninit`, or the previous `mem::uninit()`, I feel like the complexity of compiler engineering is leaking into the programming language itself and I'd like to be shielded from that if possible. At the end of the day, what I'd love to do is declare an array in Rust, assign it no value, `read()` into it, and magically reading from said array is safe. That's roughly how it works in C, and I know that it's also UB there if you do it wrong, but one thing is different: It doesn't really ever occupy my mind as a problem. In Rust it does. [https://news.ycombinator.com/item?id=44036021 https://news.ycombinator.com/item?id=44036021]

electrograv 1y ago
> That's roughly how it works in C, and I know that it's also UB there if you do it wrong, but one thing is different: It doesn't really ever occupy my mind as a problem. In Rust it does. UB doesn’t occupy the author’s mind when writing C, when it really should. This kind of lazy attitude to memory safety is precisely why so much C code is notoriously riddled with memory bugs and security vulnerabilities.
- mk12 1y ago
  There is an important difference for this case though. It C it’s fine to have pointers into uninitialized memory as you as you don’t read them until after initializing. You can write through those pointers the same way you always do. In Rust it’s UB as soon as you “produce” an invalid value, which includes references to uninitialized memory. Everything uses references in Rust but when dealing with uninitialized memory you have to scrupulously avoid them, and instead write through raw pointers. This means you can’t reuse any code that writes through &mut. Also, the rules change over time. At one point I had unsafe code that had a Vec of uninitialized elements, which was ok because I never produced a reference to any element until after I had written them (through raw pointers). But they later changed the Vec docs to say that’s UB, I guess because they want to reserve the right to use references even if you never call a method that returns a reference.
  - Arnavion 1y ago
    This stopped being much of a problem when MaybeUninit was stabilized. Now you can stick to using &MaybeUninit<T> / &mut MaybeUninit<T> instead of needing to juggle *T / *mut T and carefully track converting that to &T / &mut T only when it's known to be initialized, and you can't accidentally use a MaybeUninit<T> where you meant to use a T because the types are different. It's not as painless as it could be though, because many of the MaybeUninit<T> -> T conversion fns are unstable. Eg the code in TFA needs `&mut [MaybeUninit<T>] -> &mut [T]` but `[T]::assume_init_mut()` is unstable. But reimplementing them is just a matter of copying the libstd impl, that in turn is usually just a straightforward reinterpret-cast one-liner.
  - nemothekid 1y ago
    Bizarre. I think I've been writing broken Rust code for a couple years. If I understand you correctly something like: let mut data = Vec::with_capacity(sz); unsafe { data.set_len(sz) }; buf.copy_to_slice(data.as_mut_slice()); is UB?
    - vgatherps 1y ago
      Yes, this is the case that I ran into as well. You have to zero memory before reading and/or have some crazy combination of tracking what’s uninitialized capacity or initialized len, I think the rust stdlib write trait for &mut Vec got butchered over this concern. It’s strictly more complicated and slower than the obvious thing to do and only exists to satisfy the abstract machine.
      - Arnavion 1y ago
        No. The correct way to write that code is to use .spare_capacity_mut() to get a &mut [MaybeUninit<T>], then write your Ts into that using .write_copy_of_slice(), then .set_len(). And that will not be any slower (though obviously more complicated) than the original incorrect code.
        vgatherps 1y ago
- o11c 1y ago
  The reason this particular UB doesn't need mindspace for C programmers is because it's not even meaningful to do anything with the parts of the buffer beyond the written length. Most other UBs related to datums that you think you can do something with.
- usefulcat 1y ago
  I suspect that the main reason it doesn't really occupy the author's mind is that even though it's possible to misuse read(), it's really not that hard to actually use it safely. It sounds like the more difficult problem here has to do with explaining to the compiler that read() is not being used unsafely.
- lhecker 1y ago
  What I meant is that if I write a UTF8 --> UTF16 conversion function for my editor in C I can write size_t convert(state_t* state, const void* inp, void* out) This function now works with both initialized and uninitialized data in practice. It also is transparent over whether the output buffer is an `u8` (a byte buffer to write it out into a `File`) or `u16` (a buffer for then using the UTF16). I've never had to think about whether this doesn't work (in this particular context; let's ignore any alignment concerns for writes into `out` in this example) and I don't recall running into any issues writing such code in a long long time. If I write the equivalent code in Rust I may write fn convert(&mut self, inp: &[u8], out: &mut [MaybeUninit<u8>]) -> usize The problem is now obvious to me, but at least my intention is clear: "Come here! Give me your uninitialized arrays! I don't care!". But this is not the end of the problem, because writing this code is theoretically unsafe. If you have a `[u8]` slice for `out` you have to convert it to `[MaybeUninit<u8>]`, but then the function could theoretically write uninitialized data and that's UB isn't it? So now I have to think about this problem and write this instead: fn convert(&mut self, inp: &[u8], out: &mut [u8]) -> usize ...and that will also be unsafe, because now I have to convert my actual `[MaybeUninit<u8>]` buffer (for file writes) to `[u8]` for calls to this API. Long story short, this is a problem that occupies my mind when writing in Rust, but not in C. That doesn't mean that C's many unsafeties don't worry me, it just means that this _particular_ problem type described above doesn't come up as an issue in C code that I write. Edit: Also, what usefulcat said.
  - ninkendo 1y ago
    Why wouldn’t you accept a &mut [MaybeUninit<T>] and return a &mut [u8], hiding the unsafe bits that transmute the underlying reference? Something like: fn convert<'i, 'o>(inp: &'i [u8], buf: &'o mut MaybeUninit<u8>) -> &'o mut [u8] (Honest question, actually… because the above may be impossible to write and I’m on my phone and can’t try it.) Edit: it works: https://play.rust-lang.org/?version=stable&mode=debug&edition=2024&gist=29cb6251fbd9626910cf4d7306394562 https://play.rust-lang.org/?version=stable&mode=debug&editio...
    - lhecker 1y ago
      That's a fair workaround for my specific example. But I believe it's possible to contrive a different example where such a solution would not be possible. Put differently, I only tried to convey the overall idea of what I think is a shortcoming in Rust at the moment. Edit: Also, I believe your code would fail my second section, as the `convert` function would have difficulty accepting a `[u8]` slice. Converting `[u8]` to `[MaybeUninit<u8>]` is not safe per se.
ii41 1y ago
I think this solves his problem. He said he wants a read function that turns the unsafe buffer into a safe buffer, and this API does that. IIRC it's not that hard to convince the compiler to give you a safe buffer from a MaybeUninit. However, this type has really lengthy docs and makes you question everything you do with it. Thinking through all this is painful but it's not like you don't have to it with C.
jcranmer 1y ago
The basic problem with uninitialized buffers is that they effectively require write-only references to exist, and Rust's type system doesn't have (and doesn't easily support) write-only references, only read-only and read-write. MaybeUninit is a partial solution to the problem, but since it's a library solution and not a language solution, it suffers from a lack of integration with the language, e.g., getting MaybeUninit fields from a MaybeUninit struct is challenging. And the most aggravating part of all of this is that the most common use case for uninitialized memory (the scenario being talked about both in the article here and the discussion you quote) is actually pretty easy to have a reasonable, safe abstraction for, so the fact that the current options requires both use of unsafe code and also potentially faulty duplication of value calculations doesn't make for a fun experience. (Also, the I/O traits predate MaybeUninit, which means the most common place to want to work with uninitialized memory is one where you can't do it properly.)
- 90s_dev 1y ago
  Then is the solution to have write-only be the default for muts, so that they start out write-only at least, but can also be made to be read-write either (a) in given circumstances of creation, or (b) after certain operations on them, or (c) if created by certain APIs?
lhecker 1y ago
Abstracting away the `assume_init` is a great idea! I think I could use something like that for the editor. The only concern I have is that the `read` function is templated on the parameter type. I'd ideally _really_ prefer it if I didn't need two copies of the same function to switch over `[u8]` and `[MaybeUninit<u8>]` due to different return types. [^1] I guess the approach could be tuned to avoid this? Personally, I also like the simpler approach overall, compared to the `BorrowedBuf` trait, for the same reasons outlined in the article. While this possibly solves parts of pain points that I had, what I meant to write is that in an ideal world I could write Rust while mostly not thinking about this issue much, if at all. Even with this approach, I'd still need to decide whether my API needs to take a `[u8]` or a `Buffer`, just in the mere off-chance that a caller may want to pass an uninitialized array further up in the call chain. This then requires making the call path generic for the buffer parameter which may end up duplicating any of the functions along the path, even though that's not really my intention by marking it as `Buffer`. I think if there was a way to modify Rust so we can boldly state in writing "You may cast a `[MaybeUninit<T>]` into a `[T]` and pass it into a call _if_ you're absolutely certain that nothing reads from the slice", it would already go a long way. It may not make this more comfortable yet, but it would definitely take off a large part of my worries when writing such unsafe casts. That's basically what I meant with "occupy my mind": It's not that I wouldn't think about it at all, rather it just wouldn't be a larger concern for me anymore, for code where I know for sure that this requirement is fulfilled (i.e. similar to how I know it when writing equivalent C code). Edit: jcranmer's suggestion of write-only references would solve this, I think? https://news.ycombinator.com/item?id=44048450 https://news.ycombinator.com/item?id=44048450 [^1]: This is of course not a problem for a simple `read` syscall, but may be an issue for more complex functions, e.g. the UTF8 <> UTF16 converter API I suggested elsewhere in this thread, particularly if it's accelerated, the way simdutf is.

vgatherps 1y ago

I wish that there was a useful “freeze” intrinsic exposed, even if only for primitive types and not for generic user types, where the values of the frozen region become unspecified instead of undefined. I believe llvm has one now? Iirc the work on safe transmute also involves a sort of “any bit pattern” trait? I’ve also dealt with pain implementing similar interfaces in Rust, and it really feels like you end up jumping through a ton of hoops (and in some of my cases, hurting performance) all to satisfy the abstract machine, at no benefit to programmer or application. It’s really a case where the abstract machine cart is leading the horse

CJefferson 1y ago
I agree, I'd go further and say I wonder why primitive types aren't "frozen" by default. I totally understand not wanting to promise things get zeroed, but I don't really understand why full UB, instead of just "they have whatever value is initially in memory / the register / the compiler chose" is so much better. Has anyone ever done a performance comparison between UB and freezing I wonder? I can't find one.
- wrs 1y ago
  That assumes the compiler reserves one continuous place for the value, which isn’t always true (hardly ever true in the case of registers). If the compiler is required to make all code paths result in the same uninitialized value, that can limit code generation options, which might reduce performance (and performance is the whole reason to use uninitialized values!). Also, an uninitialized value might be in a memory page that gets reclaimed and then mapped in again, in which case (because it hasn’t been written to) the OS doesn’t guarantee it will have the same value the second time. There was recently a bug discovered in one of the few algorithms that uses uninitialized values, because of this effect.
  - CJefferson 1y ago
    But, I wonder how much it would reduce performance, if we only have to pick a value the first time the memory is read? I would imagine there isn't that many cases where we are reading uninitalised memory and counting on that reading not saving a value. It would happen when reading in 8-byte blocks for alignment, but does it happen that much elsewhere?

leoh 1y ago

Just dropping to C for a smallish segment of a rust program kind of makes sense if you want to eke out performance here, no?

bjackman 1y ago
You can always just use unsafe. This is about how to allow code to do this without unsafe blocks.
Arnavion 1y ago
It does, though even for a small segment you end up needing a lot of boilerplate - a dependency on the cc crate, a build.rs that invokes the cc crate, extern declarations to tell the Rust caller about the C function, potentially some bindgen if your small segment is not so small ... and you still end up having to do some amount of thunking between & / * / MaybeUninit because of that anyway. So if there is a "pure Rust" way to do it with `unsafe`, writing that is often easier. The pure Rust impl also has the advantage that you can validate it with Miri, unlike the C impl case because Miri cannot emulate arbitrary C code.
- leoh 1y ago
  This is a good point and perhaps points to an opportunity with cargo, macros, the rust language, or other aspects of the build system.
IshKebab 1y ago
Yeah but the C toolchain is a huge pain, and makes things like cross-compiling and compiling to WASM harder. It's really nice if you can keep your program pure Rust. Go has similar characteristics.
- nottorp 1y ago
  > compiling to WASM I thought Rust was supposed to be a systems language?
  - 1y ago

briansm 1y ago

Pardon my ignorance, but I thought the whole point of Rust was to be a 'safe' modern alternative to C, so all new buffers would be zero'd at a neglible-these-days cost. Why is rust half-assing this?

vlovich123 1y ago
It’s not. That is the case. But in cases where “negligible-these-days” isn’t quite negligible enough, this still matters and unsafe + MaybeUninit is the escape hatch to accomplish it.
- Arnavion 1y ago
  Also not every type has a valid "all zeroes" value in the first place.
- briansm 1y ago
  Yuck. In my mind, 'using C and not using Rust in the first place' is the escape hatch and Rust shouldn't even go there. Jeez, what a mess.
  - JoshTriplett 1y ago
    This is why we're spending substantial energy building better abstractions that don't require you to write any unsafe code.
  - vlovich123 1y ago
    Rust provides all the safety guarantees of managed languages with none of the performance drawbacks. It’s precisely intended to replace C/C++ because the unsafe parts of Rust are used very sparingly and result in significantly fewer bugs and security vulnerabilities. Safe abstractions for dealing with uninitialized memory efficiently are important in very niche scenarios to get optimal code out of the compiler and for reducing the ability to make a mistake when writing such code. Reaching for C to do this is an emotional overreaction instead of calmly dealing with a small corner case that already has workarounds even if it does involve using unsafe

sqrt_1 1y ago

Related to unspecified vs undefined. I recall some C code was trying to be tricky and read from just allocated memory. Something like: int* ptr = malloc(size); if(ptr[offset] == 0) { } The code was assuming that the value in an allocated buffer did not change. However, it was pointed out in review that it could change with these steps: 1) The malloc allocates from a new memory page. This page is often not mapped to a physical page until written to. 2) The reads just return the default (often 0 value) as the page is not mapped. 3) Another allocation is made that is written to the same page. This maps the page to physical memory which then changes the value of the original allocation.

Arnavion 1y ago
A read from an unmapped page producing a different value than reading from that same page after it's mapped is an OS bug (*). If this was an already allocated page that had something written to it, reading from it would page it back in and then produce the actual content. If this was a new page and the OS contract was to provide zeroed pages, both the read before it was mapped and the read after it was mapped would produce zero. What could happen is that the UB in that code could result in it being compiled in a way that makes the comparison non-deterministic. (*): ... or alternatively, we're not talking about regular userspace program but a higher privilege layer that is doing direct unpaged access, but I assume that's not the case since you're talking about malloc.
- sqrt_1 1y ago
  It was from C++con 2016 - Facebook take on small strings https://www.youtube.com/watch?v=kPR8h4-qZdk&t=1343s https://www.youtube.com/watch?v=kPR8h4-qZdk&t=1343s I believe it is about a page that was conditionally returned to the kernel.
  - Arnavion 1y ago
    The speaker was mistaken / misspoke. The closest thing to "conditionally returned to the kernel" is if the page had been given to madvise(MADV_FREE), but that would still not have the behavior they're talking about. Reading and writing would still produce the same content, either the original page content because the kernel hasn't released the page yet, or zero because the kernel has already released the page. Even if the order of operations is read -> kernel frees -> write, then that still doesn't match their story, because the read will produce the original page content, not zero. That said, the code they're talking about is different from yours in that their code is specifically doing an out-of-bounds read. (They said "If you happen to allocate a string that's 128 bytes, and malloc happens to return an address to you that's 128 bytes away from the end of the page, you'll write the 128 bytes and the null terminator will be the first byte on the next page. So they're very clearly talking about the \0 being outside the allocation.) So it is absolutely possible to have this setup: the string's allocation happens to be followed by a different allocation that is currently 0 -> the `data[size()] != '\0'` check is performed and succeeds -> `data` is returned to the caller -> whoever owns that following allocation writes a non-zero value to the first byte -> whoever called `c_str()` will now run off the end of the 128B string. This doesn't have anything to do with pages; it can happen within the bounds of a single page. It is also such an obvious out-of-bounds bug that it boggles my mind that it passed any sort of code review and required some sort of graybeard to point out.

mleonhard 1y ago

> without doing anything hugely inefficient, such as initializing the full buffer Is this so inefficient? If your code is very sensitive to IO throughput, then it seems preferable to re-use buffers and pay the initialization once at startup. Some years ago, I needed a buffer like this and one didn't exist, so I wrote one: https://crates.io/crates/fixed-buffer https://crates.io/crates/fixed-buffer . I like that it's a plain struct with no type parameters.

MaulingMonkey 1y ago
> Is this so inefficient? It can be. If you have large buffers (tuned for throughput) that end up fulfilling lots of small requests for whatever reason, for example. And there's always the occasional article when someone rediscovers that replacing malloc + memset with calloc can have massive performance savings thanks to zeroing by the OS only occuring on first page fault (if it ever occurs), instead of an O(N) operation on the whole buffer up front. Which, if in the wrong loop, can quickly balloon from O(N) to O(scary). https://github.com/PSeitz/lz4_flex/issues/147 https://github.com/PSeitz/lz4_flex/issues/147 https://github.com/rust-lang/rust/issues/117545 https://github.com/rust-lang/rust/issues/117545 If I'm reading that log-log plot right, that looks like a significantly worse than 100x slowdown on 1GB data sets. Avoiding init isn't the only solution, of course, but it was a solution. > then it seems preferable to re-use buffers Buffer reuse may be an option, but in code with complicated buffer ownership (e.g. transfering between threads, with the thread of origination not necessarily sticking around, etc.), one of the sanest methods of re-use may be to return said buffer to the allocator, or even OS. > and pay the initialization once at startup. Possibly a great option for long lived processes, possibly a terrible one for something you spawn via xargs.

pornel 1y ago

Couple of things that are commonly misunderstood/unappreciated about this: • Uninitialized bytes are not just some garbage random values, they're a safety risk. Heartbleed merely exposed unitialized buffers. Uninit buffers can contain secrets, keys, and pointers that help defeat ASLR and other mitigations. As usual, Rust sets the bar higher than "just be careful not to have this bug", and therefore the safe Rust subset requires making uninit impossible to read. • Rust-the-language can already use uninitialized buffers efficiently. The main issue here is that the Rust standard library doesn't have APIs for I/O using custom uninitialized buffers (only for the built-in Vec, in a limited way). These are just musings how to design APIs for custom buffers to make them the most useful, ergonomic, and interoperable. It's a debate, because it could be done in several ways, with or without additions to the language.

ajross 1y ago
> Uninitialized bytes are not just some garbage random values, they're a safety risk. Only when read. Writing to "uninitialized" memory[1] and reading it back is provably secure[2], but doesn't work in safe Rust as it stands. The linked article is a proposal to address that via some extra complexity that I guess sounds worth it. [1] e.g. using it as the target of a read() syscall [2] Because it's obviously isomorphic to "initialization"
- pornel 1y ago
  Obviously, initialized memory isn't an uninitialized memory any more. There are fun edge cases here. Writing to memory through `&mut T` makes it initialized for T, but its padding bytes become de-initialized (that's because the write can be a memcpy that also copies the padding bytes from a source that never initialized them).
  - lilyball 1y ago
    Note that if you have a `&mut T` then the memory must already be initialized for T, so writing to that pointer doesn't initialize anything new (although as you say it can deinitialize bytes, but that only matters if you use transmute or pointer casting to get access to those padding bytes somehow).

az09mugen 1y ago

With so much unsafe, it makes me think of that fun experimental usage of rust : https://github.com/tsoding/Crust https://github.com/tsoding/Crust