RustCrypto / hashes

Collection of cryptographic hash functions written in pure Rust
1.82k stars 247 forks source link

Hash functions not working on bare metal #452

Closed KRACK-BIT closed 1 year ago

KRACK-BIT commented 1 year ago

Hi, I'm trying to follow the basic demo for sha3 directly on a micro controller, but every time I invoke hasher.finalize(), it crashes.

Original message: https://rustcrypto.zulipchat.com/#narrow/stream/260036-general/topic/Kyber/near/327275368

Every time I invoke hasher.finalize() on my microcontroller, it will crash, no matter the data I'm using; it jumps to cortex_mrt::DefaultHandler () and does not progress any further.

The below code I'm running is meant to follow the sample code for sha3 almost identically:

#![no_main]
#![no_std]

use panic_semihosting as _; // you can put a breakpoint on `rust_begin_unwind` to catch panics
                            // use panic_abort as _; // requires nightly
                            // use panic_itm as _; // logs messages over ITM; requires ITM support
                            // use panic_semihosting as _; // logs messages to the host stderr; requires a debugger

use cortex_m_rt::entry;
use cortex_m_semihosting::hprintln;

#[entry]
fn main() -> ! {
    use sha3::{Digest, Sha3_256};

    let mut hasher = Sha3_256::new();
    let data = b"Hello world!";
    hasher.update(data);
    // `update` can be called repeatedly and is generic over `AsRef<[u8]>`
    hasher.update("String data");
    // Note that calling `finalize()` consumes hasher
    hprintln!("hasher finalizing input");
    let hash = hasher.finalize();
    hprintln!("hasher finalized input");
    hprintln!("Binary hash: {:?}", hash);

    loop {
        panic!("Done!")
    }
}

I'm running this on an xmc4500 microcontroller, my build command is cargo run --target thumbv7em-none-eabihf --example sha3, I'm debugging in gdb and this is connecting to openocd. I'm not sure if there's maybe something I'm missing, but are there any pitfalls I'm missing for when running RustCrypto modules on hardware?

tarcieri commented 1 year ago

There's nothing specific to no_std targets which would cause an incompatibility. These crates should work fine on Cortex-M targets, although we don't exactly CI them directly on bare metal hardware.

It sounds like this might be a panic? If you have semihosting set up on your device, can you get the panic message? That's the next thing we really need to debug.

KRACK-BIT commented 1 year ago

NOTE: this issue is mainly being discussed here rn: https://rustcrypto.zulipchat.com/#narrow/stream/260041-hashes/topic/sha3/near/327285820

KRACK-BIT commented 1 year ago

There's nothing specific to no_std targets which would cause an incompatibility. These crates should work fine on Cortex-M targets, although we don't exactly CI them directly on bare metal hardware.

It sounds like this might be a panic? If you have semihosting set up on your device, can you get the panic message? That's the next thing we really need to debug.

I have semihosting set up, and I can get panic messages that way (e.g. if I remove the hasher.finalize() statement, I can read the Done! panic message). However, I get nothing here; rather, it hits an infinite loop for DefautlHandler_ with no associated messages. I've checked, and the breakpoint I hit is associated with unhandled exceptions. I'm rn investigating if I can't see anything due to my debugger setup (I've been advised to use https://github.com/knurling-rs/probe-run), and will keep y'all informed if I get something out that way

KRACK-BIT commented 1 year ago

Ok, so I've been trying to get probe-run to worm on XMC4500, but so far no luck - see https://github.com/knurling-rs/probe-run/issues/386

I also have little to no progress on actually getting the sha3 library working on my micro-controller; I'm currently trying to work with a local build of the library (i.e. { path="sha3", version = "0.10.6", default-features = false }, but no luck so far

tarcieri commented 1 year ago

Per the Zulip discussion, it sounded like this is crashing inside of a memcpy and that there is something wrong with the memcpy intrinsic for your platform, which might indicate some kind of linking error.

It did not seem directly related to the sha3 crate.

tarcieri commented 1 year ago

Closing as an environment-specific problem unrelated to the sha3 crate