Should __getrandom_custom use "Rust" ABI? #345

Activity

1. josephlr

   changed the title [-]Should __getrandom_custom use "Rust" ABI[/-] [+]Should __getrandom_custom use "Rust" ABI?[/+] on Mar 10, 2023
2. newpavlov commented on Mar 10, 2023

   

   newpavlov

   on Mar 10, 2023

   Member

   More actions

   Panic safety is a strong argument for using the "Rust" ABI. I think we can start with the minimal change of switching to it (i.e. we still will use fn(*mut u8, usize) -> u32 as signature). In hypothetical v0.3 we may expose __getrandom_custom with slice-based signature instead of relying on the macro.
3. notgull commented on Mar 10, 2023

   

   notgull

   on Mar 10, 2023

   More actions

   In theory, you could also catch the panic and either abort on it or pass it around later as an error.
4. LegionMammal978 commented on Mar 10, 2023

   

   LegionMammal978

   on Mar 10, 2023

   Last edited by LegionMammal978

   More actions

   The ABI instability of extern "Rust" could be an issue here. Nothing's stopping __getrandom_custom() from being defined in a cdylib compiled with a different compiler version than the final program using getrandom_inner(). That would make it UB to call the extern "Rust" function across the boundary.

   Aborting on panic is not all that difficult. It can be done most easily with a drop guard that causes a double panic:

   extern "C" fn example() -> Output {
       struct PanicOnDrop;
       impl Drop for PanicOnDrop {
           fn drop(&mut self) {
               panic!("callback panicked");
           }
       }
       let guard = PanicOnDrop;
       let output = callback();
       core::mem::forget(guard);
       output
   }

   It would be a lot trickier to pass the full payload across the boundary, since, as before, neither a full Box<dyn Any + Send + Sync> nor a formatted String would be compatible across a cdylib. But just to continue the panic without the same payload would be feasible, by turning the panic into an error code and panicking again. (There are a few pitfalls in that, though.)
5. newpavlov commented on Mar 10, 2023

   

   newpavlov

   on Mar 10, 2023

   Last edited by newpavlov

   Member

   More actions

   Nothing's stopping __getrandom_custom() from being defined in a cdylib compiled with a different compiler version than the final program using getrandom_inner().

   I think A LOT of crates will break under such scenario, since doing so is not officially supported by Rust toolchain right now. We probably can safely ignore this concern.

   Not catching potential panics will be the least surprising behavior for users, so I don't think we should do it unless absolutely necessary.
6. josephlr

   closed this as completedin #347on Mar 14, 2023
7. josephlr

   added a commit that references this issue on Mar 14, 2023

   Switch the custom backend to Rust ABI (#347)

   ...

   This issue will close once commit 41cc07a is merged into the 'master' branch.

   41cc07a
8. takumi-earth

   added a commit that references this issue on Jan 27, 2026

   Switch the custom backend to Rust ABI (rust-random#347)

   ...

   This issue will close once commit f1a2f8c is merged into the 'master' branch.

   f1a2f8c