Various enhancements for e asm.cpu

[Maijin]

Old message

During r2con several people expressed concern about the current way e asm.cpu (models of CPU) works, especially the fact that it requires to touch code for adding new CPU IO description https://github.com/radare/radare2/blob/master/libr/syscall/ioports.c#L11-L18 where it could go in a CPU files. (Parsing from (cmsis/SWD) via a script and put info in a sdb.txt for example)

Also it has been said that `e asm.cpu` in arm contains currently cortex-m and v8 where it should contains chips models like in AVR and therefore there should be a way to describe the ISA and the chipset. `e asm.cpu` is also said to be underused and could contain much more interesting information on the models to be discussed.

I have opened an HackMD for discussion https://hackmd.io/IwYwRgbBwJwCYFoBmBDJSEBYDsAmbCYK4hKAzAKxJiWa65JA

Warning/error message if there is no such asm.cpu also got mentionned - https://github.com/radare/radare2/issues/7179

ping @killabytenow @queenp @dukebarman @Darkkey @brainstorm @xvilka

Store system registry information

Tasks:

• R_syscall_sysreg to work and tested (add tests in radare2-regressions)
• Remove all hardcoded sysreg from .h and .c files and use dedicated plaintext/sdb files per CPU instead

Store CPU information

Tasks:

• asm.cpu to be dynamically populated by listing the available CPU dedicated plaintext/sdb files
• Add RAM_SIZE info in the CPU files and remove hardcoding from .h and .c files
• Add ROM_SIZE info in the CPU files and remove hardcoding from .h and .c files
• Add INTERRUPT_VECTOR_SIZE info in the CPU files and remove hardcoding from .h and .c files
• Add IO_REGISTERS info in the CPU files and remove hardcoding from .h and .c files
• Add EXTENDED_IO_REGISTER info in the CPU files and remove hardcoding from .h and .c files

Examples of files which needs to be cleanup and improved

• https://github.com/radare/radare2/blob/master/libr/syscall/ioports.c
• https://github.com/radare/radare2/blob/master/libr/anal/p/anal_avr.c#L76-L106

Examples - using hardcoded values

• https://github.com/haystack-ia/radare-funhouse/blob/master/STM32F103XX.r2
• https://github.com/fluxchief/binaryninja_avr/blob/master/chips/iom16.py

Examples Using SVD (Subtasked into radareorg/radare2#15484)

• https://awesomeopensource.com/project/al3xtjames/ghidra-firmware-utils
• https://github.com/posborne/cmsis-svd
• https://github.com/posborne/cmsis-svd/pull/86/files
• https://github.com/leveldown-security/SVD-Loader-Ghidra
• https://github.com/rust-embedded/svd
• https://github.com/posborne/cmsis-svd

Other projects

• https://blogs.coreboot.org/blog/2019/08/22/gsoc-ghidra-firmware-utilities-wrap-up/

[queenp]

Quick opinions I have on this:
asm.cpu is not currently used in a consistent fashion. E.g.

• AVR, it refers to chipset (atmega1280, etc).
• For ARM it refers to choice between cortex (aka ARMv7) or v8 ARMv8 for the specific ARM instruction set supported.

The hardware ecology is enormous and I think it is useful as a general "cpu family"/"Instruction set" label.

From my PoV, what I would like is to have a way of importing existing hardware data description documents (e.g. https://github.com/posborne/cmsis-svd ) so that reversing stuff on particular chipsets is easier - if you see a ldr r0,[0x40013804] on an stm32l4x6 it can be flagged as a read on the CR2 register for the USART1 peripheral and not require continuously referring to the datasheet to look up memory mapped peripheral accesses to understand what they're doing.

Initially it wouldn't have to be able to do anything clever like emulation, just automatically recognising an address is listed in a system view description document selected by the user.

The document format is specified here for general purpose further information. I understand they're not always consistent and often unofficial, but even a minimal python wrapper -> r2 specification converter would be surprisingly helpful (and it would leverage all the work that has been done elsewhere creating system descriptor files in the first place). At the same time, an additional benefit would be that by the bulk of describing peripherals outside of r2, it becomes the responsibility of people maintaining those chipset documents, etc rather than a huge maintenance burden in the core project handling less "obvious" io configurations (like 32bit registers which are remapped repeatedly in slices across a 1kb to give safe bit slice accessing). This is important because there are thousands of differently configured chips around, so it's not feasible to implement new functionality for each, even for trivial differences.

At the same time I understand that support for AVR has run in to some similar, related issues. I don't know so much about them, but I think it's important to create an integrated system with good separation of responsibilities between components so it's ergonomic for users to configure for whatever they're hacking on (like me, I really want to be able to do this with r2, and I can already do similar by register addresses as flags, but I suspect it could be better. :-) ).

[queenp]

Similar parseable documents also exist for AVR devices, in a somewhat different format (ATDF)

http://packs.download.atmel.com/

[XVilka]

Check my previous unfinished PR for this. Will update it a bit later

…

On Sep 11, 2017 12:18 AM, "Maijin" ***@***.***> wrote: During r2con several people expressed concern about the current way e asm.cpu (models of CPU) works, especially the fact that it requires to touch code for adding new CPU IO description (https://github.com/radare/ radare2/blob/c0c0cba3398466661afed716f709f1fc404a752e/libr/syscall/ ioports.c#L11) where it could go in a CPU files. (Parsing from (cmsis/SWD) via a script and put info in a sdb.txt for example) Also it has been said that e asm.cpu in arm contains currently cortex-m and v8 where it should contains chips models like in AVR and therefore there should be a way to describe the ISA and the chipset. e asm.cpu is also said to be underused and could contain much more interesting information on the models to be discussed. I have opened an HackMD for discussion https://hackmd.io/ IwYwRgbBwJwCYFoBmBDJSEBYDsAmbCYK4hKAzAKxJiWa65JA ping @killabytenow <https://github.com/killabytenow> @queenp <https://github.com/queenp> @dukebarman <https://github.com/dukebarman> @Darkkey <https://github.com/darkkey> @brainstorm <https://github.com/brainstorm> @XVilka <https://github.com/xvilka> — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <https://github.com/radare/radare2/issues/8467>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAMZ_VWQf7AGmXHDlCiXU1MqApr37UQjks5shAvKgaJpZM4PSXfs> .

[XVilka]

Basically I'm suggesting to use syscalls-like approach for both IO ports and MMIO mapped registers - like here radareorg/radare2#8473

[Maijin]

See https://github.com/fluxchief/binaryninja_avr/blob/master/chips/iom16.py too

[Maijin]

Seems to define the name of the CPU, RAM_SIZE, ROM_SIZE, INTERRUPT_VECTOR_SIZE, IO_REGISTERS/EXTENDED_IO_REGISTERS. We should do this for this part of the code https://github.com/radare/radare2/blob/master/libr/anal/p/anal_avr.c#L15-L247

[radare]

ive merged the sysreg pr and rewrote it. so now the things are like this:

• rsyscall have a new api called r_syscall_sysreg() that accepts a type and a number to get the name of it
• this information is stored in Sdb
• overrides sysports information (the idea is that we will use sdb for io ports too)
• this file depends on arch+bits+cpu (OS is ignored)

[XVilka]

I will offer 0.1 BTC to the one who will fix this issue. Initially, I wanted to use BountySource, but its support for bitcoins is a plain nightmare. So I will offer it directly.

[deepakchethan]

I am interested in doing this, and will start working on it post RSoC :)

[Maijin]

@deepakchethan if you are on telegram we can sync to discuss this task together with @XVilka

[deepakchethan]

@Maijin, Yes I am on telegram. I will ping you on it :)

[XVilka]

@deepakchethan so, are you up for this task?

[deepakchethan]

Yes, i'm going through a lot of changes in my IRL and will get back to radare2 contributions by the end of this week. I am sorry about the delay.

[XVilka]

@deepakchethan any updates regarding this one?

[ghost]

I am working on r_syscall_sysreg. Where do you want to store the info on io, reg, mem?
If we store this info in the sdb file it is interpreted as an array.

[ghost]

We could have a collection of sdb file for every specific archi, and the user could load the specific file if he want.
example: archi-info-chiprandom.sdb
with something like this inside

mem.09090.name=truc
mem.09090.comment='fait un truc'

reg.rtruc.comment='est vraiment super utile'

[Maijin]

Good enthusiast but wait 😄 - there is a lot to do here, don't rush things out, don't forget that this issue is meant as a full project for GSOC, you will have to come up with a calendar/planning you'll discuss with the mentor of that project! But yes one of the idea is to have files with the configuration per CPUs instead of hardcoded configuration.

Understanding and making r_syscall_sysreg working is a first step - check how that's working now and you can improve it on the model of the e asm.describe and a simple sdb structure.

[ret2libc]

This issue has been moved from radareorg/radare2 to radareorg/ideas as we are trying to clean our backlog and this issue has probably been created a long while ago. This is an effort to help contributors understand what are the actionable items they can work on, prioritize issues better and help users find active/duplicated issues more easily. If this is not an enhancement/improvement/general idea but a bug, feel free to ask for re-transfer to main repo. Thanks for your understanding and contribution with this issue.