Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Ghidra-based AVR Lifter #1228

Open
wants to merge 3 commits into
base: master
Choose a base branch
from
Open

Ghidra-based AVR Lifter #1228

wants to merge 3 commits into from

Conversation

ivg
Copy link
Member

@ivg ivg commented Oct 6, 2020

Current State

Since LLVM is not yet ready for AVR we switched to Ghidra. We still have to use LLVM as a loader (and it proves to fail on AVR as well, but we addressed it). The lifter and decode work well so far, but we lack good testing binaries to be sure about that. The data model of the lifter (namely the registers) is not yet clear.

We will try adding some tests before merging.

@ivg ivg marked this pull request as draft October 6, 2020 15:42
@ivg ivg force-pushed the avr branch 4 times, most recently from 018ff17 to 671b859 Compare October 6, 2020 20:13
@ivg ivg changed the title [Draft] initial scaffolding for the AVR target [Draft] AVR Lifter Oct 6, 2020
@ivg ivg changed the title [Draft] AVR Lifter Ghidra-based AVR Lifter Jul 7, 2021
@ivg ivg marked this pull request as ready for review July 7, 2021 21:13
@ivg ivg force-pushed the avr branch 3 times, most recently from aa81f60 to 5f0b9ac Compare July 8, 2021 18:37
@ivg ivg closed this Dec 1, 2021
@ivg ivg deleted the avr branch December 1, 2021 19:15
@ivg ivg restored the avr branch December 2, 2021 20:29
@ivg ivg reopened this Dec 2, 2021
@ivg ivg force-pushed the avr branch 2 times, most recently from 248a8fd to 8894ec1 Compare March 14, 2022 15:13
ivg added 3 commits March 16, 2022 09:50
Current State
-------------

1) Works with only the latest versions of LLVM (11 and above)
2) the instructions so far implemented: ADC, ADD, LDI

Design Issues
-------------

A unique feature of AVR is that it maps registers directly to RAM,
thus we theoretically can't represent registers as variables, but
instead shall model them as memory addresses[^1]. Treating
this AVR feature fairly, will render quite hard to read and to analyze
code. After digging through the forums, datasheets, compilers source
code, and grepping avr-objdump outputs, we can presume that C compilers
are not leveraging this feature and use normal reads and writes to
access registers, instead of loads and stores. And the memory-mapping
of registers is mostly reserved RAM-less AVR boards, where 32 register
plays the role of minimal RAM. Of course, it doesn't mean that the
malicious code can't exploit this.

With this in mind, we still decided to model AVR as normal
register-based machine but add a command-line option later, that will
enable a conservative model, that lacks registers. Formally, our
current lifter implementation (the one with registers) just assumes
that all addresses in load and stores operation are greater than 32.

[^1]: And yes, `*0 = 'B'` is a perfectly valid code on AVR that writes `0x42` into the `R0`
register.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

1 participant