Hacktoberfest 2026：メンテナが10月に向けて印を付けた、オープンで初心者向けの issue。 Hacktoberfest の issue を見る

Framework for asm

オープン
  • 何か問題がありますか？
#168 コメント 4 件 リアクション 0 件 担当者 1 名 GitHub で見る

メンテナーはふだん 1 日以内に返信

@mwcw がすでに取り組んでいます。

2026年10月12日 から。

評価

難易度
5/5
見積もり時間
1週間以上
初心者へのやさしさ
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分
マージ済み PR（30日）
3

環境構築

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

bcgit/bc-rust のほかの issue

bcgit/bc-rust の issue をすべて見る

似ている issue

Rust の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。