ibex
ibex copied to clipboard
lowRISC
[dv] PMP Coverage Holes
The significant coverage holes in PMP are all related to instruction side accesses.
At the top-level pmp_iside_nomatch_cross`pmp_iside2_nomatch_cross` which cover scenarios where a fetch doesn't match any PMP entry (and hence may be denied or allowed depending upon MMWP and U or M mode execution) has one missing bin involving M mode and several involving U mode.
The M mode bin requires a setup without any executable regions and MMWP set. This is a possible scenario but hard to hit without a directed test. It's also not a sane configuration that would be used by software so concern over missing coverage is low for V2 here. We also have confidence that this would work as we do hit various scenarios where M mode execution is denied and M mode dside (store/load) accesses are denied due to lack of matching regions so the general logic here is sound.
Most of the holes are around U mode, indicating we don't have many scenarios where we execute U mode code without any U mode executable regions setup. For similar reasons to above this is not a major concern for V2.
Within the regional coverage pmp_iside_priv_bits_cross and pmp_iside2_priv_bits_cross have the most holes. These cover all scenarios of attempted execution against all PMP configurations, all privilege levels and deny/allow. The missing scenarios are mostly around U mode execution against various different PMP configurations. We do see some deny and allow scenarios for U mode execution showing the general logic is sound so these holes aren't a major concern for V2.
There are also a small number of holes around M mode execution allow/deny and dside load/store accesses. These occur as the random PMP config generation simply doesn't generate all possible configs. There are few of them and with no particular pattern so they aren't a major concern for V2.
estimate 4
Estimate range: 2 - 4
These should be mostly/entirely filled by the directed test work. Remaining work is to get that running in nightly regression and assess coverage impact.
New directed tests have significantly improved PMP coverage. Some small holes remain but these are mostly low priority. We still don't hit the U mode related error cases in pmp_iside_nomatch_cross and pmp_iside2_nomatch_cross other than the scenario where we don't set any of the new ePMP bits in mseccfg. It would be worth covering some of these with a simple directed test with the remaining holes to be addressed at a later point.
From a recent regression run (outside of the standard nightly regression so the full directed test suite could be included) remaining PMP holes are all around attempting to execute code from U mode. We haven't covered attempted U mode execution of a number of different region types, in particular those that are locked (L, LR, LWR, LX, LXR). For V2.5 it would be worth having a directed test to cover at least some of these scenarios.
Additionally there are some holes in pmp_wr_exec_region which covers attempting to setup new M-mode executable regions when MML is set. Each individual permission that enables M-mode execution has been seen but this is crossed with the existing permissions and some aspects of this cross aren't being hit (e.g. we may have attempted writing a M-mode execute only region in general but haven't tried it when it's specifically overwriting an M-mode read-write region). This aren't a large concern.
Directed test to stimulate U mode execution of locked regions in PR here: https://github.com/lowRISC/ibex/pull/2052 this closes the relevant coverage holes.