Add Zisb extension

[aswaterman]

This draft PR incorporates the proposed Zisb extension and will not be merged until it has been ratified.

cc @ved-rivos @dkruckemyer-work @gfavor

[github-actions]

Normative Rule Changes Detected

This PR modifies normatively tagged text. Please review the changes below to ensure they are intentional.

View Detected Changes

Normative Tag Change Report

riscv-spec Specification

================================================================================
Tag Changes Report
================================================================================

Reference file: ref/riscv-spec-norm-tags.json
Current file: build/riscv-spec-norm-tags.json
Added 2 tags:
  * "norm:pma_amo_ziccamoc_req": "The Ziccamoc extension requires AMOCASQ level
support to main memory regions with both the coherence..."
  * "norm:pma_mag_zama16b_req": "The Zama16b extension requires MAG16 support to main
memory regions."

Modified 31 tags:
  * "norm:Zca_align16":
      Reference: "The C extension allows 16-bit instructions to be freely
intermixed with 32-bit instructions, with th..."
      Current:   "The ext:zca[] extension allows 16-bit instructions to be freely
intermixed with 32-bit instructions,..."
  * "norm:Zca_hints":
      Reference: "A portion of the RVC encoding space is reserved for microarchitectural
HINTs. Like the HINTs in the ..."
      Current:   "A portion of the ext:zca[] encoding space is reserved for microarchitectural
HINTs. Like the HINTs i..."
  * "norm:Zca_no_misaligned":
      Reference: "With the addition of the C
extension, no instructions can raise instruction-address-misaligned
excep..."
      Current:   "With the addition of the ext:zca[]
extension, no instructions can raise instruction-address-misalign..."
  * "norm:Zca_offsets_mul2":
      Reference: "As with base RVI instructions, the offsets of all RVC
control transfer instructions are in multiples..."
      Current:   "As with base RVI instructions, the offsets of all ext:zca[]
control transfer instructions are in mul..."
  * "norm:Zcmop_instr_write":
      Reference: "Unlike the MOPs defined in the Zimop extension, the C.MOP.n instructions
are defined to not write an..."
      Current:   "Unlike the MOPs defined in the extlink:zimop[] extension, the C.MOP.n instructions
are defined to no..."
  * "norm:Zcmop_op":
      Reference: "This section defines the "Zcmop" extension, which defines eight 16-bit MOP
instructions named C.MOP...."
      Current:   "This section defines the ext:zcmop[] extension, which defines eight 16-bit MOP
instructions named C...."
  * "norm:Zilsd_sd_x0":
      Reference: "If using x0 as src of SD or C.SDSP, the entire 64-bit operand is zero — i.e., register x1 is not acc..."
      Current:   "If using x0 as src of SD, the entire 64-bit operand is zero — i.e., register x1 is not accessed."
  * "norm:Zimop_mop-r_op":
      Reference: "The Zimop extension defines 32 MOP instructions named MOP.R.n, where
n is an integer between 0 and 3..."
      Current:   "The ext:zimop[] extension defines 32 MOP instructions named MOP.R.n, where
n is an integer between 0..."
  * "norm:Zimop_mop-rr_op":
      Reference: "The Zimop extension additionally defines 8 MOP instructions named
MOP.RR.n, where n is an integer be..."
      Current:   "The ext:zimop[] extension additionally defines 8 MOP instructions named
MOP.RR.n, where n is an inte..."
  * "norm:c-addiw_op":
      Reference: "C.ADDIW is an RV64C-only instruction that performs the same
computation but produces a 32-bit result..."
      Current:   "C.ADDIW is an XLEN=64-only instruction that performs the same
computation but produces a 32-bit resu..."
  * "norm:c-addw_op":
      Reference: "C.ADDW is an RV64C-only instruction that adds the values in
registers rd′ and rs2′, then
sign-extend..."
      Current:   "C.ADDW is an XLEN=64-only instruction that adds the values in
registers rd′ and rs2′, then
sign-exte..."
  * "norm:c-flwsp_op":
      Reference: "C.FLWSP is an RV32FC-only instruction that loads a single-precision
floating-point value from memory..."
      Current:   "C.FLWSP is an RV32FC-only instruction that loads a single-precision
floating-point value from memory..."
  * "norm:c-jal_op":
      Reference: "C.JAL is an RV32C-only instruction that performs the same operation as
C.J, but additionally writes ..."
      Current:   "C.JAL is an XLEN=32-only instruction that performs the same operation as
C.J, but additionally write..."
  * "norm:c-ld_op":
      Reference: "C.LD is an RV64C-only instruction that loads a 64-bit value from
memory into register rd′. It comput..."
      Current:   "C.LD is an XLEN=64-only instruction that loads a 64-bit value from
memory into register rd′. It comp..."
  * "norm:c-ldsp_op":
      Reference: "C.LDSP is an RV64C-only instruction that loads a 64-bit value
from memory into register rd. It compu..."
      Current:   "C.LDSP is an XLEN=64-only instruction that loads a 64-bit value
from memory into register rd. It com..."
  * "norm:c-sd_op":
      Reference: "C.SD is an RV64C-only instruction that stores a 64-bit value in
register rs2′ to memory. It computes..."
      Current:   "C.SD is an XLEN=64-only instruction that stores a 64-bit value in
register rs2′ to memory. It comput..."
  * "norm:c-sdsp_op":
      Reference: "C.SDSP is an RV64C-only instruction that stores a 64-bit value in
register rs2 to memory. It compute..."
      Current:   "C.SDSP is an XLEN=64-only instruction that stores a 64-bit value in
register rs2 to memory. It compu..."
  * "norm:c-slli_shamt5":
      Reference: "For RV32C, shamt[5] must be zero; the code points with shamt[5]=1
are designated for custom extensio..."
      Current:   "For XLEN=32, shamt[5] must be zero; the code points with shamt[5]=1
are designated for custom extens..."
  * "norm:c-srli_shamt5":
      Reference: "For RV32C, shamt[5] must be zero; the code points with shamt[5]=1
are designated for custom extensio..."
      Current:   "For XLEN=32, shamt[5] must be zero; the code points with shamt[5]=1
are designated for custom extens..."
  * "norm:c-subw_op":
      Reference: "C.SUBW is an RV64C-only instruction that subtracts the value in
register rs2′ from the value in regi..."
      Current:   "C.SUBW is an XLEN=64-only instruction that subtracts the value in
register rs2′ from the value in re..."
  * "norm:imm_always_sex":
      Reference: "Except for the 5-bit immediates used in CSR instructions (<<csrinsts>>),
immediates are ..."
      Current:   "Except for the 5-bit immediates used in <<ext:zicsr,CSR instructions>>,
immediates are a..."
  * "norm:jvt_op":
      Reference: "If <<Zcmt>> is implemented then jvt must also be implemented, but can contain a read-onl..."
      Current:   "If ext:zcmt[] is implemented then jvt must also be implemented, but can contain a read-only value. I..."
  * "norm:misa_c_set_line":
      Reference: "MISA.C is set if the following extensions are selected:"
      Current:   "csr:misa[c] must be clear if any of the following holds:"
  * "norm:misa_c_set_list":
      Reference: "Zca and not F
Zca, Zcf and F (but not D) is specified (RV32 only)
Zca, Zcf and Zcd if D is specified..."
      Current:   "ext:zca[] is not implemented
MXLEN=32, ext:f[] is implemented, and ext:zcf[] is not implemented
ext:..."
  * "norm:misa_extensions_enc_tbl":
      Reference: "Bit|Character|Description
===
0
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25|A
..."
      Current:   "Bit|Character|Description
===
0|A|Atomic extension¶1|B|B extension¶2|C|Compressed extension¶3|D|Doub..."
  * "norm:mstatus_mdt_clr_mnret":
      Reference: "The MNRET instruction, provided by the Smrnmi extension, sets the MDT bit to 0 if the new privilege ..."
      Current:   "When the Smdbltrp extension is implemented, the MNRET instruction, provided by the Smrnmi extension,..."
  * "norm:mstatus_mdt_clr_mret_sret":
      Reference: "The MRET and SRET instructions, when executed in M-mode, set the MDT bit to 0."
      Current:   "The MDT bit is set to 0."
  * "norm:priv_combs_tbl":
      Reference: "Number of levels|Supported Modes|Intended Usage
===
1
2
3|M
M, U
M, S, U|Simple embedded systems
Sec..."
      Current:   "Number of levels|Supported Modes|Intended Usage
===
1|M|Simple embedded systems¶2|M, U|Secure embedd..."
  * "norm:priv_levels_tbl":
      Reference: "Level|Encoding|Name|Abbreviation
===
0
1
2
3|00
01
10
11|User/Application
Supervisor
Reserved
Machin..."
      Current:   "Level|Encoding|Name|Abbreviation
===
0|00|User/Application|U¶1|01|Supervisor|S¶2|10|Reserved| ¶..."
  * "norm:sstatus_sdt_clr_mnret":
      Reference: "If it is U, VS, or VU, then sstatus.SDT is also set to 0."
      Current:   "If the Ssdbltrp extension is also implemented, and the new privilege mode is U, VS, or VU, then ssta..."
  * "norm:sstatus_sdt_clr_mret_sret":
      Reference: "If the new privilege mode is U, VS, or VU, then sstatus.SDT is also set to 0."
      Current:   "If the Ssdbltrp extension is also implemented, and the new privilege mode is U, VS, or VU, then ssta..."

================================================================================
Summary: 33 total changes
  Added:    2
  Deleted:  0
  Modified: 31
================================================================================

---

What happens next:

• This comment is informational only and does not block merging
• When this PR is merged, a GitHub issue will be automatically created with the NormRules label for CSC tracking
• If these changes are unintentional, please update the PR before merging

How to update reference files (if needed):

make update-ref
git add ref/*.json
git commit -m "Update normative tag reference files"

Note: New tags (additions) are automatically added to the reference files when PRs are merged to main. Only modifications and deletions require manual review.

This comment was automatically generated by the normative tag check workflow.

[omasanori]

How about adding these citations?

[aswaterman]

Thanks @omasanori @topperc: I haven't carefully read the spec myself recently; I was just dumping it into this PR.

[topperc]

Thanks @omasanori @topperc: I haven't carefully read the spec myself recently; I was just dumping it into this PR.

Is there a different place I should put my comments?

[aswaterman]

Nope, here is perfect.

[luisgerhorst]

Is there any spec that clarifies which instructions may constitute a cache-based side channel? (I guess it will be load/store/branch?) If this is specified, it will allow unpriv eBPF to add DPB before those instructions to prevent data-value prediction from being used for exploits.

[luisgerhorst]

Is there a way to detect whether a CPU model does data-value prediction? If not, unpriv eBPF will just always have to insert (many) DPB barriers no matter if the CPU is affected. The barriers might behave like a nop on unaffected CPUs, but it might still increase the code size significantly.

[lfiolhais]

Is there a way to detect whether a CPU model does data-value prediction? If not, unpriv eBPF will just always have to insert (many) DPB barriers no matter if the CPU is affected. The barriers might behave like a nop on unaffected CPUs, but it might still increase the code size significantly.

The mconfigptr CSR contains information about the capabilities of the hart
your code is executing on. It should be inspected prior to generating code.
However, AFAIA there is no normative way to provide the information you are
seeking. If I'm not mistaken, someone was working on a specification for the
structure mconfigptr point to. I can't find the repo for the specification,
though.

[aswaterman]

I agree it's reasonable to want to be able to determine this information in a standard way, but it can come later rather than being coupled to this spec. Conservatively emitting lots of DPBs, which will execute as NOPs on most processors, is not the end of the world. eBPF's code generation can always be optimized in future, once there's a standard way to know which barriers are needed on a given implementation.