Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

specify M-bit behaviour when there's no integer mode #507

Merged
merged 1 commit into from
Jan 16, 2025
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
8 changes: 5 additions & 3 deletions src/insns/acperm_32bit.adoc
Original file line number Diff line number Diff line change
Expand Up @@ -61,12 +61,14 @@ The rules from <<acperm_rules>> must be followed when removing permissions.
| 13 (RV32 only) | <<x_perm>> | (<<c_perm>> and <<lm_perm>> and <<el_perm>> and (<<sl_perm>> == ∞)) or +
(not(<<c_perm>> and not(<<lm_perm>>) and not(<<el_perm>>) and (<<sl_perm>>==0)))^1^
| 14 | <<asr_perm>> | <<x_perm>>
| 15^2^ | <<m_bit>> | <<x_perm>>
| 15^2^ (RV32 only) | <<m_bit>> | <<x_perm>> and {cheri_default_ext_name} is implemented
|===

^1^ All the listed permissions in the set are either minimum or maximum. +
^2^ The <<m_bit>> only exists if {cheri_default_ext_name} is implemented.
Otherwise it is reserved and this rule is not relevant.
^2^ For RV32, the encodings which have the <<m_bit>> set to {int_mode_value} for {cheri_int_mode_name}
are only valid if {cheri_default_ext_name} is implemented. Otherwise those encodings represent invalid permissions.

CAUTION: For RV64 without {cheri_default_ext_name}, the <<m_bit>> is a _reserved_ bit, and so is not relevant to ACPERM.

The behavior of currently illegal combinations from <<acperm_rules>> is to clear the permission if invalid (or in the case of <<sl_perm>> set it to 0 (_local_)).

Expand Down
11 changes: 8 additions & 3 deletions src/riscv-hybrid-integration.adoc
Original file line number Diff line number Diff line change
Expand Up @@ -22,7 +22,7 @@ is a new unprivileged register: the default data capability, <<ddc>>, that is
used to authorize all data memory accesses when in
{cheri_int_mode_name}.

The current CHERI execution mode is given by the <<m_bit>> field of <<pcc>> that
The current CHERI execution mode is given by the <<m_bit>> of <<pcc>> that
is encoded as described in xref:m_bit[xrefstyle=short].

The CHERI execution mode impacts the instruction set in the following ways:
Expand Down Expand Up @@ -55,7 +55,7 @@ Setting both registers to <<infinite-cap>> ensures that:
* The bounds authorize accesses to the entire address space i.e base is 0 and
top is 2^MXLEN^

[#m_bit,reftext="CHERI Execution Mode Encoding"]
[#m_bit,reftext="M-bit"]
=== CHERI Execution Mode Encoding

{cheri_default_ext_name} adds a new CHERI execution Mode field (M) to
Expand All @@ -66,10 +66,15 @@ when the <<x_perm>> is set.
_even though it is not a permission_ as shown in <<cap_perms_encoding32>>.
** Only quadrant 1 represents executable capabilities, and so it's the only
one which encodes the Mode.
* When MXLEN=64, the Mode is encoded separately; a new <<m_bit>> field is
** If {cheri_default_ext_name} not implemented, then setting the <<m_bit>> to
{int_mode_value} for {cheri_int_mode_name} in quadrant 1 causes the permissions
to be invalid, i.e. an encoding which cannot be produced by <<ACPERM>>.
* When MXLEN=64, the Mode is encoded separately; a new <<m_bit>> is
added to the capability format as shown in
xref:cap_perms_encoding64[xrefstyle=short].
The <<m_bit>> is only valid for code capabilities, otherwise the field is reserved.
** When {cheri_default_ext_name} is not implemented then the bit allocated to the <<m_bit>>
is _reserved_ for future use.

NOTE: Mode is encoded with permissions for MXLEN=32, but is not a permission. It is
orthogonal to permissions as it can vary arbitrarily using <<SCMODE>>.
Expand Down
Loading