RISC-V Sleigh for Parsing Operands of Custom Instructions - where did it come from?

[evm-sec]

Hi all - got a real stumper here. Devs will love this - Ghidra is getting something right I'd just like to know why it's getting it right. :-D

RISC-V custom instructions are the wild west and I've seen discussions elsewhere about adding support for specific processors that have documented extensions. But this is about how Ghidra handles the general case of instructions in the custom opcode space.

Ghidra/Processors/RISCV/data/languages/riscv.custom.sinc

Is where RISC-V custom instructions are handled. Ghidra is following a convention to determine whether those instructions have 0,1, or 2 source operands, e.g.:

:custom0.rs1 rs1 is op0001=0x3 & op0204=0x2 & op0506=0x0 & op1214=0x2 & rs1
{
        custom0.rs1(rs1);
}

:custom0.rs1.rs2 rs1,rs2 is op0001=0x3 & op0204=0x2 & op0506=0x0 & op1214=0x3 & rs1 & rs2
{
        custom0.rs1.rs2(rs1, rs2);
}

(op1214 corresponds to the field commonly called "funct3" or "cf_id1" in the RISC-V documentation. So if the function field is 2 we're going to say it's a single operand, if the function field is 3 we're going to say it has two operands, etc.)

The question is: where did this convention come from? I can't find any guidance in RISC-V documentation (historical or current) that defines it this way. There is currently a "Custom Composable Extensions" draft specification but it suggests the custom-0 space be used for 2-register r-type instructions and the custom-1 space be used for 1-register I-type instructions. My guess is that maybe some of the proposed extensions were following this convention at some point? (but I couldn't find evidence of that either).

The reason I ask is that I have a sans-hardware firmware image I'm working with (so I know it's RISC-V, I know it's using custom extensions, but I have no clue what the actual target processor is) ...and Ghidra seems to be getting the operand parsing right for the custom-0 space. So in trying to determine what kind of custom extensions my target processor might be using I'd love to know where Ghidra got this convention from.

@GhidorahRex looks like he has something he's working from in this commit so maybe he can shed some light on the situation? The commit history on the file doesn't have any clues. I saw this was added due to this discussion also that @mumbel was involved in.

Thanks all - really appreciate all of the work that goes into this awesome tool.

[mumbel]

Looking at old riscv-opc.h in binutols, this logic has been removed. I most certainly scripted parsing these back when this was originally developed (~2019-2020).

[evm-sec]

So that's a lead- I guess I need to pull RISC-V specs from about that time. I can check binutils Git history too to see if they have anything relevant.

[thixotropist]

Binutils currently supports xthead, core-v, sifive, and ventana custom RISCV instructions along with a few dozen standard extensions.
I'm working up support for many of these in https://github.com/thixotropist/ghidra/tree/isa_ext - and likely trampling over existing Ghidra sleigh and pcodeop conventions in the process. This might be a good time for the developers to share thoughts on how to handle:

• identification of operands as IN, OUT, or IN/OUT
• typed pcode operands, or the ability to overide types in the decompiler window
• varadic pcodeops, especially when handling optional v0 mask operands in vector instructions
• pcode semantics that require loops
• pcode semantics that depend on the hart's vector length
• pcode proliferation that impacts emulation

[evm-sec]

I can't really comment for the devs, but suffice it to say that the way custom ops are parsed currently is wrong (it happens to work on my processor :-D, but it's not generalizable).

[evm-sec]

Actually from what I can tell now it's just the correct way to parse custom0 operands on a SiFive processor, because they use RoCC/SCIE to generate the instructions. Not sure about the other custom spaces.

[evm-sec]

It looks like the support for those instructions come from the Rocket Chip project (one of the open source implementations) that at one point had an Xcustom extension (see bminor/binutils-gdb@cb4ff67)