Physical Memory Protection (PMP)

[Frank Buss]

Which open source RISC-V cores implement PMP, as described in the privileged ISA specification? Couldn't find it in the smaller cores like VexRiscv or PicoRV32, and searching for it with Google mostly results in marketing material.

And another question: is anyone participating in the security contest?

[Frank Buss]

Found one:

https://github.com/chipsalliance/rocket-chip/blob/master/src/main/scala/rocket/PMP.scala

and someone sent me an eMail about this one:

https://github.com/pulp-platform/riscv/blob/master/rtl/riscv_pmp.sv

PS: Interesting that the Chisel implementation needs only 1/4 lines of code compared to the SystemVerilog implementation.

[Eric Smith]

On Sat, Aug 10, 2019, 14:00 Frank Buss <programmer...@gmail.com> wrote:

And another question: is anyone participating in the security contest?

Not me. I would have liked to, but clearly they learned NOTHING from the last one. This contest is a bigger challenge, but with nowhere near enough time available.

[Charles Papon]

Right, VexRiscv only implement the supervisor mode MMU

[Frank Buss]

On Sunday, August 11, 2019 at 12:56:00 AM UTC+2, Eric Smith wrote:

On Sat, Aug 10, 2019, 14:00 Frank Buss <programme...@gmail.com> wrote:

And another question: is anyone participating in the security contest?

Not me. I would have liked to, but clearly they learned NOTHING from the last one. This contest is a bigger challenge, but with nowhere near enough time available.

It was announced on July 15 on some news sites, and deadline is September 15. That's 60 days, looks good to me. It is only 5 attacks that you have to protect against, you don't have to develop a new core, only tweak one a bit. And they provided a fully working example environment this time, which I could reproduce after some days. The organizers were helpful as well when I asked them about details for the setup (I had some problems with OpenOCD and USB).

But another question is if the contest makes much sense. I guess all of the code injection attacks could be prevented with PMP, and this is already available in some cores. So the main challenge would be to port one of the PMP implementations of the big cores to one of the small cores, to get higher scores for the size and power consumption categories, and to integrate it somehow without modifying the attack program. The return-to-libc attack might be a bit more interesting.

Personally I think it is better to use a safe language like Rust or even C#, and not hardware or compiler band-aids to fix broken languages like C. Especially with simple IoT systems with basically only one big Zephyr program. For Linux this can be different, if there are multiple user mode applications, but for such bigger systems there are already interesting concepts like the MultiZone implementation etc.

[Charles Papon]

:D https://github.com/pulp-platform/riscv/blob/master/rtl/riscv_pmp.sv#L455 :D

[Tommy Thorn]

I exactly feel the same way.

In addition to all the work from the previous contest, you also have to do compiler work.

There's a crazy amount of work required.

I disagree with the whole premise and would rather just rewrite my code in any of the

billion languages which doesn't have these C/C++ problems (and frankly adding hardware

support for any those would be way more interesting than stopping C++ from shooting the foot off).

I imagine the only participants would be those who have a 100% finished core already and for whom time is free.

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/CAFrGgTRTxRryKzhODe9nJZkS%3DsZZ726ab4wwMpD6v6m%2BA-BGRw%40mail.gmail.com.

[Frank Buss]

On Monday, August 12, 2019 at 10:13:20 PM UTC+2, Tommy Thorn wrote:

I imagine the only participants would be those who have a 100% finished core already and for whom time is free.

I don't think you have to write your own core. The goal is to implement the security features. If you manage to setup somehow the PMP registers to the right values for a core that supports it, without modifying the attack code itself, then 3 of the 5 attacks are already impossible. No need to change anything in such a core. I'm working now on the remaining 2 attacks.

[Changyi Gu]

Hi, Frank

Sorry for the late reply. I just saw your post.

And I'm also planning to joining the contest, although my wife constantly complains about my nocturnal life style :-(

For the 5 attacks, you are right as the Attack #1, #2, and #5 can be easily thwarted by memory protection.

Although #3 can be stopped by using a separate buffer to store the return addresses, and copying the stored return address back during jal ra, xxx, it is hard to do so in hardware as the hardware has to be tied to the stack frame format (Please correct me if I'm wrong, as I might miss-read the paper). And such solution does not handle attack #4.

So here is what I have in mind for #3 and #4, as they are both indirect attacks:

1) identify the buffer copy operation

2) identify the indirect pointer manipulation, such as  *(uint32_t *) (*(uint32_t *) target_addr) = ...

3) Flag the pointer in step (2)

4) If the pointer in step (3) is used as return address or function pointer, throw an exception.

Thanks!

Changyi