cva6 icon indicating copy to clipboard operation
cva6 copied to clipboard

[BUG] Allowing illegal access to addresses outside the PMP range and memory boundaries.

Open youzi27 opened this issue 1 year ago • 7 comments

Is there an existing CVA6 bug for this?

  • [X] I have searched the existing bug issues

Bug Description

EDIT: The CVA6 can access an address beyond the PMP boundaries and memory limits without triggering an exception, whereas Spike does throw a trap_load_access_fault exception. Regardless of whether virtual address translation is enabled or not.

The log is as follows:

core   0: 0x00000000800040a6 (0x3a002f73) csrrs   t5, pmpcfg0, zero
3 0x00000000800040a6 (0x3a002f73) x30 0x000000000000000f
core   0: 0x00000000800040aa (0x3b002ef3) csrrs   t4, pmpaddr0, zero
3 0x00000000800040aa (0x3b002ef3) x29 0x0000000080004030
core   0: 0x00000000800040ae (0x3b1023f3) csrrs   t2, pmpaddr1, zero
3 0x00000000800040ae (0x3b1023f3) x 7 0x0000000000000000
core   0: 0x00000000800040b2 (0x000f9683) lh      a3, 0(t6)
3 0x00000000800040b2 (0x000f9683) x13 0xffffffffffffab1e mem 0x7ffffffffffffff0

youzi27 avatar Apr 18 '24 12:04 youzi27

Hi, thanks for the report.

I am a bit confused about the issue. As far as I remember, PMP ranges are tested in the CI using the PMP test/benchmark in riscv-tests. This tests both accesses that should fail and accesses that should pass. It also checks both NAPOT and TOR configurations. I do not fully understand the new CI, but it seems that CVA6 is still passing this test (or benchmark). It is a bit confusing that your test case fails, but the thousands of tests within the PMP test/benchmark all pass.

From my own experience, PMP test setups can be quite complex, e.g., they often include setting up physical to virtual page mappings. Could you post your entire test case? Or explain what the rest of your setup looks like? That would make debugging this way easier.

Some initial sanity checks: Are you sure your access should be blocked? I.e., did you test your failing test case on a simulator like Spike?

Moschn avatar Apr 18 '24 14:04 Moschn

Hi @Moschn ,

Thank you for your prompt response. Spike throw a trap_load_access_fault exception. Correction: The above situation occurred in M mode(The CVA6 can access an insanely large address in M-mode. ).

EDIT: Regardless of whether virtual address translation is enabled or not.

You can run the following assembly code:

main:
		  la x24, test_pmp
                  li x15, 0x0
                  add x24, x24, x15
                  csrw 0x3b0, x24
                  li x24, 0xf
                  csrw 0x3a0, x24
                  sfence.vma
mepc_setup:
		  la x15, test_pmp
                  csrw 0x341, x15
custom_setup: 
		  li t6,0x1fffffffffff

rand_init_mode:
		  csrw satp,zero              
                  li x11, 0xa0010ba00
                  csrw mstatus, x11 
                  li x11, 0xa0010ba00
                  csrw sstatus, x11 
                  mret
test_pmp:
lw s7, -2048(t6)
lh a3, 1(t6)
j _exit

youzi27 avatar Apr 18 '24 14:04 youzi27

Thanks for the test case.

As far as I can see, your test executes the load in M-mode. PMP checks are usually not enforced in M-mode. M-mode accesses are only checked against PMP entries with the lock bit set.

Priv spec (3.7 Physical Memory Protection):

PMP checks are applied to all accesses whose effective privilege mode is S or U, including instruction fetches in S and U mode, data accesses in S and U mode when the MPRV bit in the mstatus register is clear, and data accesses in any mode when the MPRV bit in mstatus is set and the MPP field in mstatus contains S or U. PMP checks are also applied to page-table accesses for virtual-address translation, for which the effective privilege mode is S. Optionally, PMP checks may additionally apply to M-mode accesses, in which case the PMP registers themselves are locked, so that even M-mode software cannot change them until the hart is reset. In effect, PMP can grant permissions to S and U modes, which by default have none, and can revoke permissions from M-mode, which by default has full permissions.

Moschn avatar Apr 19 '24 07:04 Moschn

Thank you for your reply.

I agree that it is optional whether M-mode is restricted by PMP, but what I mean is that in M-mode, cva6 can access a non-existent physical address (a very large address that exceeds the memory space) without causing any page access exceptions.

Thank you.

youzi27 avatar Apr 19 '24 07:04 youzi27

Ah now I get it. Sorry for my confusion.

I am no expert in the RISC-V ISA nor in CVA6, but as far as I know, accesses outside of the memory map are supposed to throw access fault exceptions without checking the PMPs. So if this is a bug, it is probably unrelated to PMPs.

I vaguely remember that CVA6 used to just read a static value for accesses outside of addressable memory. It might have changed since then though. And I am not sure if this complies with the standard.

Moschn avatar Apr 19 '24 09:04 Moschn

No worries, it's possible that my description was limited by the use of two restrictive terms, 'PMP' and 'memory boundaries,' which might have made the latter easily overlooked. You are correct; if cva6 in M-mode is not restricted by PMPs, it should still adhere to the memory boundaries. Note: I have observed a similar issue on other processor and it has been confirmed.

Thank you very much for your reply and insights!

youzi27 avatar Apr 19 '24 09:04 youzi27