今日的行程：

讀書室：09:30-11:00

正片開始

今日的記錄：

Smstateen/Ssstateen

也是這幾天學到的 extension，有個很有趣的名字 S mstate en，是針對 state enable 這個 register 做的一些控制

發想

• RISC-V 有可選擇要不要實作的 extension，這些 extension 有可能會有安全性的疑慮，假如有某個 extension 新增了一些處理器的狀態 (processor state)，通常是指新增 register 但也有可能有其他形式的狀態，但 OS 或是 hypervisor 不知道，而這些 register 是可以被 User 或是 Guest OS 存取的話，那這樣不同的 user thread 或是不同的 Guest OS 之間就會有一個祕密通道 (Covert Channel) (ref)
• 具體實例，Spec 是用 AIA 來說明，AIA 新增了 10 個 S mode CSR，並且也支援向後相容 (backward compatibility)，所以不支援 AIA 的軟體也可以運行在有 AIA 支援的硬體上，但這些軟體就不會知道 AIA 新增的這些 CSR，也就是說 guest OS 之間可以用這些 CSR 作為秘密通道來溝通，雖然先前會覺得這個祕密通道無害，但對於資訊安全極為重視的現在，覺得會需要有方法來關閉這個祕密通道。

解決方法

• Floating extension 和 Vector extension 也會有這個問題，但是因為 {m,s}status register 上面有 FS 或是 VS 欄位來控制這些 CSR 或是 extension 指令可否執行。
  • F 或是 V extension，是在 mstatus 或是 sstatus 新增欄位，但是這個方法擴增性很差，幾乎是不可行，因為 {m,s}status 的欄位有限
• Smstateen/Ssstateen 也就應運而生，新增了 mstateen0-3、ssstateen0-3 還有 hstateen0-3 (如果有支援 H extension)
  • 如果是 32 bit，就還會有高位的部分，例如: mstateen0, mstateen0h，但是 s mode 的 sstateen 沒有
  • stateen CSR 的每一個 bit 代表的是，更低層級的 mode 是否有權限存取這個 bit 代表的 extension 的狀態 (extension's state)，和 counteren CSR 運作機制相同。
  • 各有 4 個 CSR 是因為 256 個 bit 看起來是一個相對合理的數字，不太多以致於定義了多餘的 CSR 欄位，也不太少以至於欄位不夠用。

使用方式

直接上圖

• 每個 bit field 是在控制更低的層級可不可以使用該 extension，例如 mstateen0 的 FCSR bit 就是標示 S mode 是否可以存取 fcsr。
• Quotes from Spec:

On reset, all writable mstateen bits are initialized by the hardware to zeros. 
If machine-level software changes these values, 
it is responsible for initializing the corresponding writable bits of 
the hstateen and sstateen CSRs to zeros too. 
Software at each privilege level should set its respective stateen CSRs to
indicate the state it is prepared to allow less-privileged software to access.

總結

• 遇到的問題是，有 smstateen 支援所以造成一些 S mode 的 CSR 存取會需要看 mstateen 放不放行，不放行的話就會遇到 illegal instruction 然後跳到 M mode 的 trap handler

Reference

• Privileged Spec Chapter 4. "Smstateen/Ssstateen" Extensions, Version 1.0