| Message ID | 20230904140040.33153-1-thuth@redhat.com |
|---|---|
| Headers | show |
| Series | Add support for s390x to RISU | expand |
On Mon, 2023-09-04 at 16:00 +0200, Thomas Huth wrote: > Hi Peter! > > Here are some patches that add basic support for s390x to RISU. > It's still quite limited, e.g. no support for load/store memory > operations yet, but the basics with simple 16-bit or 32-bit > instructions work already fine. > > (In the long run, we'd need to support instructions with 48-bit > length on s390x, too, since most newer "interesting" instructions > like e.g. vector SIMD instructions are encoded with 48 bit. This > will require modifications to the generic code, too, so I limited > my initial implementation to 16-bit and 32-bit instruction length > support to keep the code self-contained in the s390x architecture > specific files) What's also interesting about SIMD, is that floating-point instructions clobber the upper parts of vector registers. I wonder if there is a way to systematically solve this? In my scripts the solution isn't pretty: insn = gdb.execute("x/i $pc", to_string=True) print(insn) gdb.execute("stepi") if "%f" in insn: [ Skip comparison ] I think there are also a few cases in non-SIMD areas, where PoP basically says "if conditions X and Y hold, the output is unpredictable". One other thing - for not-so-near future - is it possible to integrate this with coverage-based fuzzers? I.e., somehow generate the instructions based on the coverage signal. Maybe even make sure that the signal comes from JITed code too. I wanted to try AFLplusplus in QEMU mode for this purpose (which would ultimately run QEMU in QEMU), but never found the time. [...]
On 04/09/2023 16.30, Ilya Leoshkevich wrote: > On Mon, 2023-09-04 at 16:00 +0200, Thomas Huth wrote: >> Hi Peter! >> >> Here are some patches that add basic support for s390x to RISU. >> It's still quite limited, e.g. no support for load/store memory >> operations yet, but the basics with simple 16-bit or 32-bit >> instructions work already fine. >> >> (In the long run, we'd need to support instructions with 48-bit >> length on s390x, too, since most newer "interesting" instructions >> like e.g. vector SIMD instructions are encoded with 48 bit. This >> will require modifications to the generic code, too, so I limited >> my initial implementation to 16-bit and 32-bit instruction length >> support to keep the code self-contained in the s390x architecture >> specific files) > > What's also interesting about SIMD, is that floating-point instructions > clobber the upper parts of vector registers. I wonder if there is a way > to systematically solve this?# No clue yet, so far the code does not support the extended vector registers yet (since the weren't part of the information that is provided by the ucontext.h header file). I guess it should be OK to check only the floating point part for the registers where it overlaps, and only check the full vector register if the register does not overlap ... I don't expect much difference for a vector instruction when it executes with register 0 - 15 compared to when it executes with register 16 - 31, so skipping half of the check for register 0 - 15 shouldn't be too bad. > One other thing - for not-so-near future - is it possible to integrate > this with coverage-based fuzzers? I.e., somehow generate the > instructions based on the coverage signal. Maybe even make sure that > the signal comes from JITed code too. I wanted to try AFLplusplus in > QEMU mode for this purpose (which would ultimately run QEMU in QEMU), > but never found the time. I don't think this is possible yet, but maybe it's be possible to write a TCG plugin for QEMU to dump the executed instructions into an input file for risu? Thomas