Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

Framework for asm

Abierto
  • ¿Algo no está bien?
#168 4 comentarios 0 reacciones 1 asignado Ver en GitHub

Los mantenedores suelen responder en 1 día

@mwcw ya está trabajando en esto.

Desde el 12/10/2026.

Evaluación

Dificultad
5/5
Tiempo estimado
Más de una semana
Aptitud para principiantes
12/100
Tipo de issue
Nueva funcionalidad
Claridad
Necesita aclaración
Estado de actividad
Activo
Stack tecnológico
rust
Área
build-system, cryptography

Línea de trabajo

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.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

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.
Lenguaje dominante
Rust
Estrellas
25
Forks
18
Merge medio
7 d 13 min
PR fusionados (30 d)
3

Preparar el entorno

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de bcgit/bc-rust

Todos los issues de bcgit/bc-rust

Issues similares

Más issues de Rust

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.