RISC-V security contest

[Frank Buss]

Anyone who got it working on the Creative board? Last contest the organizers didn't publish links to all github repositories, so was difficult to find. Maybe this time the organizers could post all github repositories, or post a reply to this posting with your entry.

I didn't manage to get it running on the board. Was still 95% fighting with the environments, learning SpinalHDL and the Libero IDE, backporting the LiteX Zephyr target for the VexRiscv core, because it was not implemented in the required old version of Zephyr etc. The actual patch for the security feature then was very easy: I added a custom CSR at 0x800, which defines a limit until it is allowed to execute code. If someone tries to jump higher, an illegal instruction exception is generated.

In the simulator I got it working, at least for the 3 attacks as described on my last posting. Here is the typical workflow and you can see the relevant changes to the VexRiscv core, which I used as the base (with the Murax SoC configuration), and the 2 line changes in the Zephyr framework to initialize the CSR register. A proper implementation would implement the full PMP extension, but this was just for a proof-of-concept.

https://www.youtube.com/watch?v=CysjqcEjFqA

As you can see at the end, I created even the Libero project, integrated the core, setup a PLL to test different core clocks. But then I needed 32 RAM1K18 blocks, because I didn't use the DDR RAM on the board, and I have only 31 blocks. I think the inferring was not very smart, because I tried to reduce it until the program didn't work anymore, but it inferred always one RAM1K18 block, as I could see in the other reports, one block for each bit of the 32 bit databus.

So it doesn't run on the real hardware, which was a rule of the contest. But it was my fault, I postponed it again until the last minute. Maybe I will finish the next contest :-)

If someone is interested in the details, here are my github repositories:

https://github.com/FrankBuss/zephyr/tree/vexriscv

https://github.com/FrankBuss/security-contest

If you want to run it yourself, you need to setup everything as described on the security contest page, then replace the zephyr directory in the zephyrproject directory with my repository, and install OpenOCD for VexRISCV:

sudo apt-get install libtool automake libusb-1.0.0-dev texinfo libusb-dev libyaml-dev pkg-config

git clone https://github.com/SpinalHDL/openocd_riscv

cd openocd_riscv

./bootstrap

./configure --enable-ftdi --enable-dummy

make

To create the VexRiscv core, which is saved as Murax.v, execute this from the other repository (after setting up Scala and SpinalHDL, and substitute the paths with your paths) :

cd ~/data/projects/security-contest/VexRiscv

sbt "runMain vexriscv.demo.Murax"

Then you can run Verlator with it:

cd ~/data/projects/security-contest/VexRiscv/src/test/cpp/murax

make clean

make run

And then you can "connect" OpenOCD to it:

cd ~/openocd_riscv

./src/openocd -f tcl/interface/jtag_tcp.cfg -c "set MURAX_CPU0_YAML /home/frank/data/projects/security-contest/VexRiscv/cpu0.yaml" -f tcl/target/murax.cfg

After you have compiled the RIPE example for the vexriscv board like this:

cd ~/RISC-V-IoT-Contest/ripe/

rm -rf build

mkdir build

cd build

cmake -DBOARD=litex_vexriscv ..

make

you can start GDB, connect to the OpenOCD instance and start the program:

cd ~/RISC-V-IoT-Contest/ripe/build/zephyr

/opt/riscv/bin/riscv32-unknown-elf-gdb zephyr.elf

run the program like this from within gdb:

target remote localhost:3333

load

c

On the Verilator window you can see the UART output, as you can see in the video.

[Tommy Thorn]

I got seriously burned by the last contest; 90% of my time was spent on things not related to the core problem (that is making a RV32I compliant core) - things like getting Zephyr working and struggling with the Microsemi dev tools.  I took one glance at the new competition and it's clear they learned nothing from the last attempt (was the number of entries actually revealed?) so don't fool me twice.

Tommy

--
You received this message because you are subscribed to the Google Groups "RISC-V Soft CPU Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to softcpu-discu...@riscv.org.
To view this discussion on the web visit https://groups.google.com/a/riscv.org/d/msgid/softcpu-discuss/a87968a3-d56f-4d91-8147-0b367e7e7215%40riscv.org.

[Frank Buss]

Right, Zephyr is a lot of work, if you are working on the low level stuff of it. It might be a nice system for application programmers (never really tried it for this), but otherwise it is just too many different files in too many different places and with too many different formats, all to be edited by hand. Reminds me a lot to Linux kernel development, which I did some years ago.

And then on top of this, all the different tools. This is really hard for one person. Maybe the organizers should encourage more teamwork? Some people like Linux kernel development, some people like FPGA programming, and there might be even people who like to setup toolchains and utility programs like OpenOCD, and who are Linux gurus. But there are not many people who can or want to do it all.

As I suggested for the last contest, a Docker container with all the required tools would be nice. Meanwhile there are already some RISC-V toolchain containers, but I don't know if there is a container with a full setup with everything needed, including Zephyr, the toolchain, OpenOCD, and maybe even Eclipse and the Microsemi SoftConsole. It should be possible to test the example project (which was very helpful for this contest) without any manual additional installation or configuration steps, ideally just one script in a Docker container which uploads and runs it.

Regarding the FPGA IDE, I start to like Libero. So far for FPGA programming in general, I tried to do it all on the source code level, mostly with VHDL. But the SmartDesign concept allows me to use my own VHDL entities without problems, and easily connect them graphically with other own entities, or IP catalog entities. Long time ago I tried the Altera schematic entry, but this was terrible, especially if you change something. With SmartDesign, it is just one mouse click to update the component, and another mouse click for an auto-layout, which gives quite good results.

Of course, this introduces the problem that it will be difficult to port or use the design to other IDEs. I guess in the long run, the open source FPGA toolchains like IceStorm will become what is GCC now. Then you would need only one IDE for all platforms. This would be good for the manufacturers as well. Imagine all FPGA manufacturers would combine their work they invest in the IDE, in one open source project. This would reduce massively the individual cost per company, but the result would be a far better IDE than any individual company could do.

I think an ideal contest would look like this:

- No Zephyr required. This is just an additional hassle and doesn't really help developing cores, which I guess is what most people here (including me) are having fun to do. Just the RISC-V toolchain is sufficient.

- With no Zephyr, it would be (relatively) easy to create a fully working Docker container with all tools and a working example program. And additionally, it would be much easier for someone to replace parts in it, like with his/her own RISC-V core, which probably would only require to edit a linker config file, or replacing a driver, which would require just to edit one C file, and everything would be still working.

- On the FPGA side, a fully working, documented and open source concept for uploading your RISC-V binaries should be implemented. Maybe this can be done with the SoftConsole, but I tried to connect it with the JTAG-port of the VexRiscv core, and it didn't work. Is the RISC-V JTAG interface standardized? This would be really helpful. But something simple, like a program upload over UART, just with a simple Python script, would be easier. It should be as easy as the Arduino environment: It has a bootloader and with one mouse click you can compile and upload your program to it.

Apropos Arduino: wouldn't it be cool, if there would be an Arduino target for the Creative Board? This makes even more sense with the Arduino headers on the board. The boards could be delivered pre-programmed with a RISC-V core and Arduino bootloader, so all the normal application user has to do is to install the Arduino IDE to program and upload RISC-V programs. Imagine something like the Arduino MKR Vidor 4000, with some pre-programmed useful entities, like UART, SPI etc., and maybe some fancy entities like PWM audio output and VGA output. And the advanced user could change the FPGA configuration to add or change HDL entities, but can still use the very easy to use Arduino IDE for the software side. The 512 MB RAM would be very interesting for more complex Arduino projects as well.

[Changyi Gu]

Hi, Frank

I've managed to get it working on the Creative board, and my repo is at

https://github.com/PulseRain/Rattlesnake

It seems the Libero for Windows (and synplify pro) uses absolute paths for linked file and library. So I have to manually change the project file to make them portable. 

Also, in order to infer the memory, I have to manually modify the netlist produced by synplify pro. Otherwise the Libero will fail.

And for the Arduino idea you mentioned, I second that 100%. In fact, here are some of the Arduino support packages I made for other dev boards (such as STEP CYC10 or Efinix Trion T20):

https://github.com/PulseRain/Arduino_RISCV_IDE

Thanks!

Changyi

[Olof Kindgren]

Of course, this introduces the problem that it will be difficult to port or use the design to other IDEs. I guess in the long run, the open source FPGA toolchains like IceStorm will become what is GCC now. Then you would need only one IDE for all platforms. This would be good for the manufacturers as well. Imagine all FPGA manufacturers would combine their work they invest in the IDE, in one open source project. This would reduce massively the individual cost per company, but the result would be a far better IDE than any individual company could do.

Fully aware that I'm drifting off topic, but as I have spent the past eight years working on reuse and portability for FPGA I would just like to mention that FuseSoC https://github.com/olofk/fusesoc was created to provide a common interface for EDA tools. It currently supports 16 different FPGA toolchains, simulators and linters. My own entry for last year's soft CPU contest of course has FuseSoC support and you can see here (https://github.com/olofk/serv/blob/master/servant.core) how few changes are required to port this between the TinyFPGA BX, Icebreaker, Nexys A7 and different simulation targets I have ported it to so far

//Olof

[Tommy Thorn]

It’s no obvious to me just how much you can leverage other peoples work and still enter the competition.  I would have expected such details to be explicit.

Not that it would have change anything for me.

Tommy

--

You received this message because you are subscribed to the Google Groups "RISC-V Soft CPU Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to softcpu-discu...@riscv.org.

To view this discussion on the web visit https://groups.google.com/a/riscv.org/d/msgid/softcpu-discuss/CAKaYPCOtqxsOu7%3D%2B6GFJhoA3W3SF-mem4Fuje9J%2BC6dCktobUQ%40mail.gmail.com.

[Frank Buss]

On Monday, September 16, 2019 at 9:17:06 AM UTC+2, Tommy Thorn wrote:

It’s no obvious to me just how much you can leverage other peoples work and still enter the competition.  I would have expected such details to be explicit.

Not that it would have change anything for me.

Tommy

The contest rules only say, that the entry must be a RV32IMC compliant core. It doesn't say that you have to develop it yourself from scratch. If the license of an existing core allows it (e.g. BSD license), then you could have used this core. The scoring doesn't contain a point for own creativity.

BTW, the contest organizers just wrote an eMail to all contestants. There were 4 entries:

- Matthew Ballance https://github.com/mballance/fwrisc-s

- Ecco team https://github.com/spacemonkeydelivers/riscv_security_contest_project

- Jörg Mische https://github.com/bobbl/rudolv

- Changyi Gu https://github.com/PulseRain/Rattlesnake.git

My entry was listed as well, because I submitted it in case there were no other entries, but as I wrote earlier, I don't consider my entry to be valid, because it didn't run on the real hardware in time.

The solution from Jör Mische looks pretty clever, at least it can detect all attacks of the sample program. But I don't think it would be useful as a general concept, because then hackers would find a way around it by writing 32 bit values, and it could false trigger on normal programs.

The solution from Changyi Gu looks like the most complicated one, but maybe the best in terms of catching more attacks and no false triggers.

Congratulations to all winners in advance, nearly all valid entries will win :-)

[Frank Buss]

On Monday, September 16, 2019 at 7:25:04 AM UTC+2, Olof Kindgren wrote:

Fully aware that I'm drifting off topic, but as I have spent the past eight years working on reuse and portability for FPGA I would just like to mention that FuseSoC https://github.com/olofk/fusesoc was created to provide a common interface for EDA tools. It currently supports 16 different FPGA toolchains, simulators and linters. My own entry for last year's soft CPU contest of course has FuseSoC support and you can see here (https://github.com/olofk/serv/blob/master/servant.core) how few changes are required to port this between the TinyFPGA BX, Icebreaker, Nexys A7 and different simulation targets I have ported it to so far

This looks very good. Maybe it can be combined with a GUI like IceStudio? See here https://icestudio.readthedocs.io/en/latest/source/userguide.html . This would make it very easy to draw portable schematics. And hopefully someday there will be an open source synthesizer for all devices, not just for some Lattice devices, so that you don't need to download the big IDEs of the vendors.

[Frank Buss]

On Monday, September 16, 2019 at 7:08:20 AM UTC+2, Changyi Gu wrote:

And for the Arduino idea you mentioned, I second that 100%. In fact, here are some of the Arduino support packages I made for other dev boards (such as STEP CYC10 or Efinix Trion T20):

https://github.com/PulseRain/Arduino_RISCV_IDE

Looks great! Does this work with your PulseRain M10 board as well? I guess it wouldn't be that much work to port the FPGA backend to the Microchip Creative Board, too. Imagine a contest with the word "Arduino" in it, for sure there would be more than 4 contestants :-)

[Changyi Gu]

Hi, Frank

The PulseRain M10 board was designed before I knew the world of RISC-V, and it has a different repo for Arduino

https://github.com/PulseRain/Arduino_M10_IDE

After I discovered the wonderful world of RISC-V, I created a new repo for all of my RISC-V cores.

https://github.com/PulseRain/Arduino_RISCV_IDE

And certainly I will add support for the Creative Board soon after this.

Thanks!

Changyi

[Jörg Mische]

Hi,

I absolutely agree that there is too much work that has nothing to do
with the core problem. It took me 2 weeks to get Libero running (btw,
here is how I did it:
https://bobbl.github.io/bobbl/bobbl.github.io/fpga/microsemi/2019/09/23/install-libero.html)
and another 2 weeks for Zephyr and the example. And less than 3 days for
the core problem.

My ideal contest is very close to Frank's:
* Bare metal, no Zephyr (a program like RIPE does not need a timer
interrupt and mul/div, but without them Zephyr crashes. And I spent much
time to implement these two unnecessary features)
* Containers for commercial FPGAs but also the possibility to use
icestorm (very easy to get into it and the synthesis time is much faster
than all the commercial tools)
* A precisely defined UART interface for receiving the binary image
and writing the output

Jörg

[Jörg Mische]

Sorry, here the correct URL to the Libero installation howto:
https://bobbl.github.io/fpga/microsemi/2019/09/23/install-libero.html