Hacktoberfest 2026：维护者为十月标记出来的 issue，仍然开放、适合新手。 浏览 Hacktoberfest issue

Framework for asm

未关闭
  • 哪里不对？
#168 4 条评论 0 个 reaction 已指派 1 人 在 GitHub 查看

维护者通常 1 天内回复

@mwcw 已经在做这个了。

开始于 2026年10月12日。

评估

难度
5/5
预计耗时
一周以上
新手友好度
12/100
Issue 类型
功能
描述清晰度
需要澄清
活跃度
活跃
技术栈
rust
领域
build-system, cryptography

调研方向

Start with the #![forbid(unsafe_code)] attribute in each crate's lib.rs and the existing crypto/utils crate, which is the one place unsafe is allowed. The issue weighs three layouts (a shared crypto/asm crate, per-algorithm *_asm crates, or an asm module behind a cargo feature) and leaves the choice open. Done means a decided layout, a cargo feature scheme that can turn the asm code off, and an UNSAFE.md with the memory-safety comment conventions. This needs maintainer input before any code is written.

由索引模型根据 Issue 内容生成。

描述

Current State

Currently, every crate's lib.rs begins with:

#![forbid(unsafe_code)]

This restricts the entire crate to the "safe" subset of the Rust language.
(the exception is the crypto/utils crate which houses zeroization and ct stuff, which requires unsafe.)

This buys us a couple of things:

  1. Guaranteed memory safety; that's not to say that unsafe / asm can't be safe, but it's not guaranteed by construction, so it needs more analysis, formal methods, etc.
  2. Portability; the safe subset is guaranteed to build for any target architecture supported by the rust compiler.

So I think having each algorithm function in a forbid(unsafe_code) mode is important to keep, and adding asm acceleration should be an opt-in feature (which I'd be happy to have on by default, as long as it's a simple compile flag to turn it back off).

Goal

As we push for better performance, we need to allow ourselves to use asm ("intrinsics") such as hw SHA2 / AES or vectorization.

(Though, LLVM is already very good at auto-vectorization, so from what I've read, you're generally better-off to write simple and straightforward code where the compiler can figure out what's vectorizable instead of trying to vectorize yourself (ex.: for loops with independent loop branches walking an array and performing a simple expression is likely already vectorized for you.)

This means that we need a pattern for adding asm to the library without impacting the #![forbid(unsafe_code)] tag on the algorithm crates.

The right answer might be something like a new crypto/asm crate with a sub-module for each algorithm:

crypto/
  asm/
    lib.rs   # contains common stuff
    aes.rs
    lattice.rs
    ... etc

Alternatives could be one *_asm companion crate per algorithm, like aes_asm/ , ascon_asm, sha2_asm, etc, but I think that will get unwieldy fast. Or housing asm as a sub-module within each algorithm crate: aes/asm.rs, but I suspect that'll be harder to cleanly separate the code that works under #![forbid(unsafe_code)] and the code that doesn't -- although maybe aes/lib.rs could have the mod asm; line be conditional on an asm cargo feature, and thereby be provably absent from the build when that feature is off, so that might be worth exploring.

We would also need:an extremely well-documented readme.md or UNSAFE.md with conventions for writing unsafe code within bc-rust. Things like keep unsafe blocks as short as possible; document a "# Memory Safety` comment block on each unsafe block with pre- and post-conditions in the style that's idiomatic of unsafe rust and compatible with analysis tools such as Miri. Document testing requirements with tools such as Miri to provide some soundness guarantees on our unsafe.

I think once we get an architecture in place for this, then we'll be able to Go Fast™ at plouging in intrinsic acceleration.

Task / Acceptance Criteria

  • Lay out a pattern for where we are going to hause unsafe / asm within the bc-rust source.
  • Lay out a pattern for how we are going to control whether to use the unsafe / asm code at the cargo build level.
  • Document all the in-house rules for unsafe / asm by mining the unsafe rust community best-practices. This should include code style, consistent documentation of memory safety conditions on each unsafe code block, and validation with existing unsafe rust proof tooling.
主要语言
Rust
星标
25
派生
18
平均合并
7 天 13 分钟
30 天内合并 PR
3

环境准备

从这里开始

  1. 先读完整个 Issue，再读项目的贡献指南。
  2. 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
  3. Fork 仓库，在一个分支上完成修改。
  4. 提交 Pull Request，并在描述里引用这个 Issue 编号。

bcgit/bc-rust 的其他 Issue

查看 bcgit/bc-rust 的全部 Issue

相似的 Issue

更多 Rust Issue

把新 issue 发到你的邮箱

精选适合新手参与的 GitHub issue 摘要。