Hacktoberfest 2026: những issue maintainer đã đánh dấu cho tháng Mười, đang mở và phù hợp người mới. Xem issue Hacktoberfest

Framework for asm

Đang mở
  • Có gì không ổn?
#168 4 bình luận 0 reaction 1 người được giao Xem trên GitHub

Maintainer thường phản hồi trong vòng 1 ngày

@mwcw đang làm issue này rồi.

Từ ngày 12/10/2026.

Đánh giá

Độ khó
5/5
Thời gian dự kiến
Hơn một tuần
Mức phù hợp với người mới
12/100
Loại issue
Tính năng
Độ rõ ràng
Cần làm rõ
Mức độ hoạt động
Sôi nổi
Công nghệ
rust
Lĩnh vực
build-system, cryptography

Hướng nghiên cứu

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.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

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.
Ngôn ngữ chính
Rust
Star
25
Fork
18
Merge trung bình
4 ngày 8 giờ
Pull request đã merge (30 ngày)
2

Chuẩn bị môi trường

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của bcgit/bc-rust

Tất cả issue của bcgit/bc-rust

Issue tương tự

Thêm issue về Rust

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.