Clarify black_box warning a bit

[saethlin]

Trying to bring the docs on black_box more in line with the advice that we have discussed in Zulip.

#140341 (comment)

[rustbot]

r? @ibraheemdev

rustbot has assigned @ibraheemdev.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

[the8472]

I'm not sure if that's quite true. For example user code might choose to use FFI and setup linking to evade LTO, I don't think std/rustc is going to jump through those kinds of hoops since it can't control linking of generic instantiations.

[Daniel-Aaron-Bloom]

Perhaps "you should not be able to use other parts of the standard library to write a better..." then?

[saethlin]

I'm not sure what you mean by evading LTO. If LTO can see through black_box it's already quite non-functional for benchmarking.

[the8472]

A weak blackbox implementation might prevent DCE of the input but not optimizations based on properties of the output value.

You can also replace LTO with other post-link optimizations such as wasm JIT and user code taking steps avoid that.

[saethlin]

A JIT can break any black box so I'm not sure what point you are trying to make.

[the8472]

A JIT will have blind spots or even explicit escape hatches and you can make a targeted blackbox using those.

The point I'm making is that users may be "able to write a better black_box" under specific circumstances and the standard library won't adopt those.

[Noratrieb]

A weak blackbox implementation might prevent DCE of the input but not optimizations based on properties of the output value.

that's an example where you could do better, and it would indeed be a buggy implementation that should be reported, as the docs say.

[the8472]

No, I meant that as an example for a hypothetical backend or target where that's the best we can do.
E.g. by making a value "escape" to a static we could prevent DCE but the backend lacks a way to make the value opaque because it's a single-threaded closed-world environment that has no concept of MMIO or interactions with the environment outside the abstract machine other than special IO instructions, so even volatile would get lowered to plain stores and loads.

[Amanieu]

I think that talking about bugs confuses the message we are trying to send. What we really want to say is that there is no mechanism in the entire Rust language that can get you the guarantees you want for constant-time cryptography: you can't do better than black_box. This should be an additional paragraph in the warning box that warns about using black_box for crypto code.

[the8472]

I think the subtlety here is that from a spec perspective all approaches are equal; they're not guaranteed, even asking the question is nonsense because the constant-time aspect is not considered an observable property etc. etc..
But the people who reach for these methods despite the warnings are ignoring the spec and care about actually generated compiler outputs.

And some other approaches such as FFI, assymbly or linker trickery just might achieve better results, under specific circumstances. So we can't really promise that this is the strongest possible implementation under all conditions.

Maybe something like

No identity function available through core is expected to fulfill all of the following conditions

• is a stronger optimization barrier than black_box
• has has no additional side-effects
• only applies to the passed value

If such a function existed it would be used to implement black_box.

[Daniel-Aaron-Bloom]

I think that talking about bugs confuses the message we are trying to send.

I strongly disagree with this. If I'm writing a crypto library that is using black_box to hide a boolean inside a u8 to stop it from being turned into branches by the optimizer and I encounter some circumstance where black_box fails, but some other standard library approach succeeds (e.g. read_volatile), then I have a security bug that I have to fix by cobbling together my own custom_black_box. It would be nice if instead I could file a bug on the standard library and point to obvious language to support it as a bug, rather than a "too bad, so sad, won't fix".

I can't speak for everyone using rust for cryptography, but I think language that helps advocate for the above use case is really important.

[ibraheemdev]

Going to pass this on to libs because it seems to be controversial. r? libs

[saethlin]

I've replaced the diff with @Amanieu's suggestion, though I'd quite like to hear from anyone who manages to get the optimization-suppressing effect they want from a volatile read but not black_box.

[RalfJung]

Cc @rust-lang/opsem

[Mark-Simulacrum]

r=me with or without Ralf's wording.

[saethlin]

@bors r=Mark-Simulacrum rollup

[bors]

📌 Commit f501775 has been approved by Mark-Simulacrum

It is now in the queue for this repository.