From: Deepak Gupta <debug@rivosinc.com>
To: "Radim Krčmář" <rkrcmar@ventanamicro.com>
Cc: opensbi@lists.infradead.org,
opensbi <opensbi-bounces@lists.infradead.org>
Subject: Re: [PATCH] lib: sbi: expected trap must always clear MPRV
Date: Tue, 25 Nov 2025 10:03:12 -0800 [thread overview]
Message-ID: <aSXvYP2OvUzePP8F@debug.ba.rivosinc.com> (raw)
In-Reply-To: <DEHQBF6B4C9L.125VJJV9WIVFK@ventanamicro.com>
On Tue, Nov 25, 2025 at 12:12:11PM +0100, Radim Krčmář wrote:
>2025-11-24T14:03:39-08:00, Deepak Gupta <debug@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.
--
opensbi mailing list
opensbi@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/opensbi
next prev parent reply other threads:[~2025-11-25 18:03 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-11-24 22:03 [PATCH] lib: sbi: expected trap must always clear MPRV Deepak Gupta
2025-11-25 11:12 ` Radim Krčmář
2025-11-25 18:03 ` Deepak Gupta [this message]
2025-11-25 18:51 ` Radim Krčmář
2025-11-25 19:17 ` Deepak Gupta
2025-11-25 19:48 ` Radim Krčmář
2025-11-25 20:04 ` Deepak Gupta
2025-11-26 8:21 ` Radim Krčmář
2025-12-26 11:06 ` Anup Patel
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=aSXvYP2OvUzePP8F@debug.ba.rivosinc.com \
--to=debug@rivosinc.com \
--cc=opensbi-bounces@lists.infradead.org \
--cc=opensbi@lists.infradead.org \
--cc=rkrcmar@ventanamicro.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox