You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The hardware automatically legalizes some certain values when writing some of the CHERI SCRs in RISC-V. Example SCRs include xTVEC, xEPCC, etc and legalization can be due illegal address as described here or the trap MODE bits in xTVEC.
From the CHERI point of view, legalization means that the capability’s address is changed under the hood to a “legal” address, so there is a call to setCapAddr in Sail to check that the new address is still representable. See here -> then here for example.
However, sealed capabilities automatically get their tag cleared even when the "legalized" address is equal to the original address in the capability to be written. So, in practice, we cannot write sealed capabilities to SCRs like xTVEC and xEPCC. Is this intentional? That behavior looks a little odd to me...
The text was updated successfully, but these errors were encountered:
integer writes using csr* instructions to address SCRs always cause CSetAddr with the mode field set to zero for Xtcc
CSpecialRW writes write the whole cap, but still call CSetAddr with the mode field set to zero for Xtcc which has the side-effect of clearing the tag of sealed caps written to Xtcc
The hardware automatically legalizes some certain values when writing some of the CHERI SCRs in RISC-V. Example SCRs include xTVEC, xEPCC, etc and legalization can be due illegal address as described here or the trap MODE bits in xTVEC.
From the CHERI point of view, legalization means that the capability’s address is changed under the hood to a “legal” address, so there is a call to
setCapAddr
in Sail to check that the new address is still representable. See here -> then here for example.However, sealed capabilities automatically get their tag cleared even when the "legalized" address is equal to the original address in the capability to be written. So, in practice, we cannot write sealed capabilities to SCRs like xTVEC and xEPCC. Is this intentional? That behavior looks a little odd to me...
The text was updated successfully, but these errors were encountered: