thread 'main' panicked at 'called `Result::unwrap() using cwe_check with bare-metal option

[Enkelmann]

Discussed in https://github.com/fkie-cad/cwe_checker/discussions/283

^{Originally posted by JavierBaratech February 2, 2022}
Hello all,

I have a problem when running cwe_checker with a bare-metal binary for an AVR chip. I have been debugging the code but I can't find the bug.

This is the input:

cwe_checker binary.bin --bare-metal-config ATxmega64B3.json

and the error:

thread 'main' panicked at 'called Result::unwrap() on an Err value: Error("missing field register_calling_convention", line: 966, column: 1)', src/caller/src/main.rs:378:64
note: run with RUST_BACKTRACE=1 environment variable to display a backtrace

With other bare-metal binaries with chips like the EFM32 I have not had any problems and the program worked correctly.

Thanks in advanced!

[Enkelmann]

This is probably related to the CPU type of the chip. Can you tell me what value is contained in the processor_id field of the ATxmega64B3.json configuration file? I could try to find a sample with the same CPU type in my firmware sources so that I can reproduce the error.

Edit: Could you also tell me which version of the cwe_checker you are using? The line number in the error message does not match the current master branch, so I am unsure whether I am looking at the right code right now.

[JavierBaratech]

The processor_id is: "avr8:LE:24:xmega"

I got this id from the avr8.ldefs file inside Ghidra/Processors/Atmel/data/languages.

When I decompile the binary in Ghidra, with that processor_id, it does it correctly.

[JavierBaratech]

Version: cwe_checker 0.6.0-dev

In latest stable version --bare-metal-config is not available.

[Enkelmann]

I have not found a sample for this processor type in my sources yet. When using this processor ID on other binaries I get a different error than what you get (which is OK, since the error suggests that the binary was indeed not compiled for this processor). Can you point me to a binary compiled for this processor type? Without it I might not be able to reproduce the error.

[JavierBaratech]

Due to confidentiality reasons I cannot provide you the binary that I am using. However I will try to get one that uses the same architecture.

The micrcontroller datasheet: http://ww1.microchip.com/downloads/en/DeviceDoc/Atmel-8074-8-and-16-bit-AVR-Microcontroller-XMEGA-B-ATxmega64B3-ATxmega128B3_Datasheet.pdf

And here is the configuration of the .json file that I have checked and I think it is correct.

{
"_comment": "The CPU architecture of the chip. Valid values are those that Ghidra accepts as processor IDs.",
"processor_id": "avr8:LE:24:xmega",
"_comment_1": "The base address, where the contents of the binary would be mapped on the chip, as a hexadecimal number.",
"flash_base_address": "0x0800000",
"_comment_2": "The base address, of the RAM memory region as a hexadecimal number.",
"ram_base_address": "0x1000000",
"_comment_3": "The size of the RAM memory region (in bytes) as a hexadecimal number.",
"ram_size": "0x1000000"
}

[Enkelmann]

The vendor website seems to provide enough resources for compiling simple example binaries for the architecture. I will try that. But it might take some days until I find the time to do this.

Edit: I found an example binary and can reproduce the error with it. So now I can finally start to work on a fix. :)

[JavierBaratech]

The vendor website seems to provide enough resources for compiling simple example binaries for the architecture. I will try that. But it might take some days until I find the time to do this.

Edit: I found an example binary and can reproduce the error with it. So now I can finally start to work on a fix. :)

That sounds great!

I really appreciate your efforts.

[Enkelmann]

OK, I managed to fix your initial issue and some other issues on top of that in #286. However, analyzing an AVR8 sample still leads to panics that now should look as follows:

thread 'main' panicked at 'assertion failed: `(left == right)`
  left: `"R23R22"`,
 right: `"R23R22R21R20"`', src/cwe_checker_lib/src/pcode/term.rs:670:21
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

Due to an old design decision the AVR8 architecture can currently not be correctly represented in the internal representation used by the cwe_checker. I suspect that other architectures with pointer sizes smaller than 32-bit may run into similar problems. This is not a problem I can easily fix, I have to put in some thought on how this could be done first.

So for the time being AVR8 unfortunately remains unsupported by the cwe_checker. Since I also do not know yet how difficult it will be to fix this I cannot give any time estimate for the fix. I will leave the issue open until I can report some progress on fixing these old design mistakes.

[JavierBaratech]

Thank you very much for your work.

I will wait for any progress on the topic.

[amarkovytch]

I have similar issue with RH850 target :
thread 'main' panicked at 'assertion failed: (left == right)
left: "r6",
right: "r6r7"', src/cwe_checker_lib/src/pcode/term.rs:670:21
note: run with RUST_BACKTRACE=1 environment variable to display a backtrace