[PATCH] lib: sbi: expected trap must always clear MPRV
Deepak Gupta
debug at rivosinc.com
Tue Nov 25 10:03:12 PST 2025
On Tue, Nov 25, 2025 at 12:12:11PM +0100, Radim Krčmář wrote:
>2025-11-24T14:03:39-08:00, Deepak Gupta <debug at rivosinc.com>:
>> Expected trap must always clear MPRV. Currently it doesn't. There is a
>> security issue here where if firmware was doing ld/st with MPRV=1 and
>> since there would be a expected trap, opensbi will continue to run as
>> MPRV=1. Security impact is DoS where opensbi will just keep trapping.
>
>Does the DoS happen on some implementation?
I ran into it while doing something else. So it was result of basically
eyeballing. Didn't observe on real system.
>
>The expected trap came from M-mode, therefore will have mstatus.MPP=3,
>so MPRV=1 should behave the same as MPRV=0.
Yeah I missed that part. You have a point here.
However if we read priv spec
"21.4.1. Machine Status (mstatus and mstatush) Registers"
...
The MPV bit (Machine Previous Virtualization Mode) is written by the
implementation whenever a trap is taken into M-mode. Just as the MPP
field is set to the (nominal) privilege mode at the time of the trap,
...
Above text seems to suggest that nominal privilege at time of trap is
set in MPP.
And then just a few paragraph below if we read,
...
When MPRV=1, explicit memory accesses are translated and protected,
and endianness is applied, as though the current virtualization mode
were set to MPV and the current nominal privilege mode were set to MPP
...
So if take them together, it seems like nominal priv at time trap can be
less than 3 and same should reflect in MPP if it gets trapped.
I don't know what implementations are doing. Should ask around.
>
>Thanks.
More information about the opensbi
mailing list