zeroize: do not rely on volatile operations?
Maintainers usually reply within 1 day
Nobody has claimed this yet.
Assessment
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Newbie friendliness
- 35/100
Research direction
Start by reviewing the zeroize implementation and the hardened black_box in zeroize/src/barrier.rs, along with the optimization_barrier change from #1252. Determine whether simple writes can replace volatile writes across the supported targets, then update the implementation and documentation consistently.
Written by the indexing model from the issue text.
Description
write_volatile docs explicitly state that:
Volatile operations are intended to act on I/O memory.
Using it on a non-volatile memory does not cause soundness issues, but it still can be considered a misuse of the function. It also can result in a very suboptimal codegen as noted in #743.
#1252 has introduced optimization_barrier which allows us to use simple writes optimizable by the compiler which are then "observed" by the barrier to prevent removal of the writes.
Unless we discover some practical issues with optimization_barrier, I think we can replace the volatile writes with simple writes. It would require changing promises made in the docs, but it should not matter in practice for downstream users.
As a potential compromise we could keep using volatile writes only on targets which do not have stable asm! macro and where optimization_barrier has to use the "hardened" black_box.
- Dominant language
- Rust
- Stars
- 674
- Forks
- 170
- Avg merge
- 1d 20h
- Merged PRs (30d)
- 7
Getting set up
We have not checked this project's setup files yet. Start from its README, and see our first-contribution guide for the general steps.
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from RustCrypto/utils
-
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
RustCrypto/utils#1546 · 1 comment ·
Maintainers usually reply within 1 day
-
Difficulty 3/5 1-2 days Newbie friendliness 55/100
RustCrypto/utils#1537 · 7 comments ·
Maintainers usually reply within 1 day
-
Difficulty 4/5 3-5 days Newbie friendliness 45/100
RustCrypto/utils#1534 · 2 comments ·
Maintainers usually reply within 1 day
-
Difficulty 5/5 Over a week Newbie friendliness 45/100
RustCrypto/utils#1529 · 5 comments ·
Maintainers usually reply within 1 day
-
Difficulty 4/5 3-5 days Newbie friendliness 45/100
RustCrypto/utils#1510 · 1 comment ·
Maintainers usually reply within 1 day
All issues in RustCrypto/utils
Similar issues
-
Difficulty 2/5 1-3 hours Newbie friendliness 84/100
vercel-labs/agent-browser#2017 ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
tursodatabase/turso#9405 ·
Maintainers usually reply within 1 day
-
bug
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
PolyMeilex/Neothesia#447 ·
Maintainers usually reply within 1 day
-
backend::vllm diffusion multimodal
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
trezor/trezor-firmware#7985 ·
Maintainers usually reply within 2 days