CNRV

关注RISC-V和Chisel以及开源IC和EDA在中国的发展

View the Project on GitHub

RISC-V 雙周簡報 (2018-01-04)

要點

新年展望

過去的一年發生了很多有趣的事情，相比去年，我能夠看到越來越多的人開始對RISC-V持有樂觀的態度。今年5月在上海舉辦的RISC-V Workshop在中國的影響是深遠的，很多國內的半導體廠商開始意識到RISC-V或許是除了AI之外最不能錯過的趨勢。當然，這當中有些廠商有心參與卻無處發力，有能力的一些廠商開始積極布局，更多的廠商打著自己的算盤悶聲發大財。不論怎樣，如果RISC-V不能給大家帶來切切實實的利益，要他又有何用？

但不論在是國內還是國外，在RISC-V的普遍好評中我都能感受到一種氣氛，那就是他們仍然在用過去20-30年的發展思路去看待RISC-V。很多人會想去做第二個Arm或是第二個Intel，我不能反駁這個思路，但我認為在技術創新的同時不能沒有有商業模式的創新，而這或許是你沒法做第二個Arm的主要原因之一。其實很難說最後會不會出現一家通過RISC-V發家的巨頭，但是RISC-V要想跨越鴻溝，被普羅大眾所接受，或許要是無數個小的力量聚合在一起所推動的。

RISC-V代表了一種“去中心化”的趨勢，這意味著每個有能力的人都可以開始使用和改進RISC-V，而且門檻會越來越低，少數有能力的人會開發出穩定可靠的開源CPU，而你或許只要掌握少量的知識和技能就可以加入自己的東西並且為我所用。這就像是在Web開發領域，大量的高性能庫、框架和可伸縮的雲計算服務能夠顯著的降低開發人員的技能門檻。

所以，在新的一年裏，讓我們學著“解放思想”，想想怎麽能把RISC-V和你們自己的優勢結合起來，來鞏固和加強你們的優勢。黑貓白貓，捉住老鼠就是好貓。

最後，CNRV會在新的一年裏繼續努力，建立更大、更健康、更活躍的社群，我們也在準備會舉辦一場大規模的線下活動，到時候可別忘了來捧場，老鐵！

Security點評

評論”英特爾CPU爆驚天漏洞”

最近一則關於“英特爾CPU爆驚天漏洞”的新聞傳遍網絡。 其實在小編看來，這則新聞並沒有那麽新，英特爾修覆漏洞是必然，只是個時間問題。 反觀RISC-V，其實RISC-V已經規避了Intel的問題，在這方面，是一個更加Security的指令集。 下面就讓我來稍微仔細一點的說一說。

有人猜測說這個漏洞和 OoO 的分支預測(branch speculation)有關，導致了低優先級的用戶程序能夠 access kernel space 。 小編個人對此解釋持保留態度。 使用分支預測已是亂序流處理器的基本配置，Intel存在漏洞而AMD幸免有些說不過去。 後來看更多的英文文檔 [Lipp2017]，其實英文裏面說的是預測執行(speculative execution)，這個就比分支預測的範圍大得多了。 其原理簡單說就是處理器允許預測執行的 U mode代碼 access 內核資料並將內核資料真的讀取並置入緩存。 從2016年CCSSecurity會議的一篇文章來看，使用Intel處理器的Linux系統早就被攻破，其關鍵也是對用戶程序的內存讀寫監管不嚴。

先簡單介紹一下基本的 kernel space 保護：基於種種原因，至少在Linux系統中， kernel space 是被完整添加到用戶進程的虛擬空間中的。 這就導致用戶程序能很容易的 access kernel space ，造成了Security隱患。 為了緩解該問題，現代內核往往使用 kernel space address 隨機化(KASLR)，隨機化之後，用戶程序需要猜出 kernel space 分布才能窺視內核。 繞過內核 address 隨機化變成了攻擊內核的重要一步。

在Sandy Bridge之後的Intel處理器允許用戶程序的prefetch指令預取任意的 address ，包括 kernel space 的 address 。 這邊提供了攻擊者創造特殊緩存時間側信道來探測 kernel space [Gruss2016]。 更糟糕的是，Linux內核將所有用戶空間都映射到了 kernel space 以方便內存管理(physmap)。 攻擊者通過尋找自己的資料空間在 kernel space 的對應映射，便能夠做到內核態代碼註入，用以劫持內核 [Gruss2014, Kemerlis2014]。

這裏暴露了很多問題：

那麽我們再來看看RISC-V。 RISC-V指令集在SSTATUS控制寄存中定義了SUMflag。 一般情況下，SUM=0，即內核態代碼不能讀寫 U mode資料，只有當必要時，內核才臨時開啟SUM直接操縱用戶資料。 但是，內核無論如何都不能執行用戶頁的指令。 這樣，即使physmap將用戶頁映射到了 kernel space ，其 page table 仍然標註該頁屬於 U mode，則徹底堵上了利用physmap對內核的代碼註入。

另外，RISC-V討論組內部也早已開始討論比Intel更加徹底的用戶和內核 page table 分離方案 [isa-dev-2017-11-30]。 當前Intel的 page table 分離方案的明顯性能下降主要來源於內核和用戶切換時需要刷新TLB，產生了大量缺頁中斷 [Gruss2017]。 如果用戶和內核使用不同的 page table base address 和ASID，則不要頻繁刷新TLB，大大降低性能損失。 由於用戶和內核的徹底 page table 分離，prefetch指令將徹底失去預取內核資料的能力，去除其造成的側信道。

(宋威：以上為個人基於有限文獻的見解，受知識面和能力限制，如有錯誤，還望不吝指正。同時感謝Shawn的審校。)

RV新聞

glibc port v3

最近 Palmer 在 glibc-alpha 上提交了 glibc port v2 和 v3。由於Debian, Fedora, OpenEmbedded 等上層軟體都仰賴 glibc 和ABI 的穩定，glibc的upstream便顯得急迫且重要。glibc的RISC-V port 將包含六個configuration。詳請可見Palmer在port v2中的介紹：

Our QEMU port is not yet upstream (we’re preparing it for submission now), and general availiability of the first commercial, Linux-capable RISC-V chips is scheduled for Q1 2018.

We’ve had preliminary ports of Debian, Fedora, and OpenEmbedded to RISC-V, all of which are currently waiting on glibc so we can declare the ABI stable.

QEMU port v1

Michael Clark 最近提交了QEMU port v1，期望能在QEMU 2.12 合並主線。這次的提交主要是針對base ISA的部分。未來，可能會再加上hypervisor extension, vector extension 和device emulation 等功能。

詳情請見：QEMU port v1

技術討論

如何支持semi-host

很多指令集都支持使用 debugger 來實現一些簡單的I/O功能以方便系統的早期調試。 這時候， debugger 便起到了一部分主機的功能，即稱作semi-host。 由於 debugger 的可見中斷只有EBREAK指令，所以實現semi-host必須在這條指令上想辦法。 在RISC-V指令集定義的時候，EBREAK指令被定義為不帶任何操作數的指令，其基本考慮如下：

From Krste:

  • A debugger knows the addresses at which it has inserted breakpoints. ( debugger 應該知道源代碼中的 breakpoint 位置)
  • When the debugger is notified that a hart has stopped at a breakpoint, it needs to read the pc at least. (當 debugger 被 breakpoint 喚醒， debugger 至少會讀取當前PC指針)
  • A debugger-side hashtable indexed by the pc can uncover all the necessary information about that breakpoint without having to go back and read the EBREAK instruction bits from target memory, and without being constrained by the size of the EBREAK immediate field. (使用一個簡單的 hash table 應該就能很快分析出 breakpoint 的功能，而不需要去分析 breakpoint 指令的參數)
  • A compressed EBREAK should work the same as an uncompressed EBREAK, and encoding space is more critical in compressed code. (壓縮和非壓縮 breakpoint 指令的行為應當一致)
  • More generally, we viewed EBREAKs as instructions that are poked into compiled code from outside, not instructions that are compiled in to a binary, though it’s clear software breakpoints are being used in this way for other architectures. (從根本上說， breakpoint 指令應當被看作被外部添加的指令，而不是原有執行程序的固有指令。盡管軟中斷被其他的Architecture大量使用為軟體基本功能)

上面的軟體中斷即暗指ARM系列的軟終端，想起來了ARM 7中SWI #imm的用法嗎？

不過這些基本假設現在似乎出現了問題。 比如，Liviu就指出， debugger 並不是任何時候都能拿到被調試代碼的執行副本的(思考直接將 debugger 接到一個嵌入式系統盲調)。 這這種時候，就不能假設 debugger 能獨立理解 breakpoint 所需要的功能。

為了解決這個問題，Liviu提議改變EBREAK的格式，添加一個立即數參數。但是這樣便破壞了已經被定義的 U modeRISC-V指令級標準。 作為折衷方案，Krste提出：

  • Use EBREAK + 16-bit zero + 16-bit tag as current workaround to lack of EBREAK immediate (effectively making a new 64-bit EBREAK encoding).   (仍然使用現在的EBRAK指令，不過在指令後添加一個16bit0的非法指令做標識符，然後使用一個16bit作為 breakpoint 參數)
  • Add “undelegate” feature to debug spec so ECALL (and other   exceptions/interrupts) can trap to debugger.   (為系統調用ECALL提供 debugger 的接口，讓部分系統調用由 debugger 完成)
  • Move eventually to using ECALL for semihosting-like applications where debug hardware supports “undelegate”.   (逐步推進使用系統調用實現semi-host的大部分功能)
  • Use labeled ELF for EBREAK “assert failure” use cases.   (使用 breakpoint 和執行文件副本實現assert)

但是即使這樣也不能滿足所有需求。 其中反映最激烈的問題是使用系統調用的方式實現semi-host導致每次host調用都必須陷入異常處理， 這對於使用semi-host來實現輕量級打印輸出來說代價過大。 用semi-host的方式實現輕量級打印輸出是trace調試的基本操作之一， 在系統早期調試硬體和基礎軟體，trace調試是非常有用的。 所以支持這種輕量級的semi-host也是很有必要。

現在這個討論還在繼續中，決定之後，RISC-V的調試標準將會做相應修改。 現在看來，對於I/O的semi-host應用會使用系統調用方式，而對於打印調試信息則可能使用 breakpoint 叫附加 breakpoint 參數的方式。

相關討論：https://groups.google.com/a/groups.riscv.org/d/msg/isa-dev/1Su9Z7L18qM/QCDxYoCCBwAJ

使用32bit的NOP指令隱藏一條16bit指令？

這個技巧還真是令人大開眼界。假設下面的程序：

if(a>0) b=b+1;
else    b=b-1;

這段小程序的else分支只有一條指令。一般編譯器會在if分支的最後加一條跳轉指令跳到else分支之後的代碼。 但是由於else分支只有一條指令，與其使用跳轉指令，可以使用一條類似LUI x0, #imm20的NOP指令（x0寄存器永遠為0，所以賦值沒有意義）， 然後將else分支的指令用一條RVC指令代替，然後將其藏在20bit的立即數裏。很有點腦洞大開。

這麽做的主要意義是節省指令空間，據說在以前的ROM大小受限的Z80系統經常會使用這種技巧。 在現代處理器中，這種使用方式基本不會帶來任何速度優勢（分支預測能很準確地預測跳轉），但可能造成取指（Fetch）部分的錯誤。 不過對於系統初始環節，在初始內存受限情況下，也許有其用途。

代碼更新

RISC-V port 針對 linux kernel 4.15-rc4 的更新

這次的更新算是修正一些小錯誤。包括：

更多細節可參考 GIT pull 的連結：link

實用資料

Linux kernel Upstream的內容（Palmer 的 All Aboard, Part 8: The RISC-V Linux Port is Upstream!）

Palmer在這篇中記錄了 4.15中 Upstream的內容，同時也講了哪些還需要加強。還需要加強的部分包括memory model、PLIC、DMA、timer、device tree文檔、以及SBI console driver。想了解Linux kernel整體的情況的話，可以參考。想了解更多更新，也可以追蹤 patches@groups.riscv.org。

連結：All aboard part 8

Palmer 的 All Aboard, Part 9: Paging and the MMU in the RISC-V Linux Kernel

前半段Palmer先介紹了 RISC-V 系統中的 AEE (Application Execution Environment)和 SEE (Supervisor Execution Environment)。在RISC-V中，AEE的部分基本要求包括(小編：scall在2.1中其實已經被更名為ecall)：

  • The ISA string, which determines what the vast majority of instructions do as well as which registers constitute the machine’s current state.
  • The supervisor’s user-visible ABI, which determines what the scall instruction does. This is different than the C compiler’s ABI, which defines the interface between different components of the application.
  • The contents of the entire memory address space.

當然，實際上AEE還是要看各操作系統決定的，譬如FreeBSD 和 Linux的AEE就不同。至於Unix-class 的 SEE，則是會由Platform spec 小組訂出一些基本要求，Palmer所猜測的定義如下(除了PMA和SBI以外，這跟workshop時小編記錄的類似）：

  • Either the RV32I or RV64I base ISAs, along with the M, A, and C extensions. The F and D extensions are optional but paired together, leaving the possible standard ISAs for application-class SEEs as RV32IMAC, RV32IMAFDC (RV32GC), RV64IMAC, and RV64IMAFDC (RV64GC).
  • On RV32I-based systems, support for Sv32 page-based virtual memory.
  • On RV64I-based systems, support for at least Sv48 page-based virtual memory.
  • Upon entering the SEE, the PMAs are set such that memory accesses are point-to-point strongly ordered between harts and devices.
  • An SBI that implements various fences, timers, and a console.

在介紹完AEE和SEE這些系統基本的要求後，Palmer整理了一些RISC-V中 page table的特點：

  • Pages are 4KiB at the leaf node, and it’s possible to map large contiguous regions with every level of the page table.
  • RV32I-based systems can have up to 34-bit physical addresses with a three level page table.
  • RV64I-based systems can have multiple virtual address widths, starting with 39-bit and extending up to 64-bit in increments of 9 bits.
  • Mappings must be synchronized via the sfence.vma instruction.
  • There are bits for global mappings, supervisor-only, read/write/execute, and accessed/dirty.
  • There is a single valid bit, which allows storing XLEN-1 bits of flags in an otherwise unused page tables. Additionally, there are two bits of software flags in mapped pages.
  • Address space identifiers are 9 bits or RV32I and 16 bits on RV64I, and they’re a hint so a valid implementation is to ignore them.
  • The accessed and dirty bits are strongly ordered with respect to accesses from the same hart, but are optional (with a trap-based mechanism when unsupported)

值得註意的是，像ASID這種額外功能在RISC-V的 Linux kernel中其實還沒實作。有興趣的同學可以把握機會。最後，Palmer介紹了跟device 和DMA有關的部分。因為RISC-V 沒有定義IOMMU，目前RISC-V linux kernel 使用 bounce buffer 及 32bit ZOME_DMA 來處理 device addressing的問題。

更多細節可以參考: Palmer 的 All aboard part 9

Sodor 的設計文檔

Shimomura Shigeki 整理了一份約20頁的Sodor design doc，詳細整理了code structure和每一個檔的作用。有在用sodor研究RISC-V，或想學chisel的可以參考。

連結：Sodor design doc

另一個chisel的學習資料：Berkeley 的 Generator Bootcamp

想透過學chisel學習rocket和BOOM的同學可以參考這個新的repo。這個 repo 用 Jupyter Notebook 來教怎麽用chisel寫generator。另外，chisel learning journey 的文檔也在不斷更新，也可以參考或加入chisel learning journey的hangout。

Links:

行業視角

34C3大會上RISC-V相關的報道

你恐怕要先問什麽是34C3，34C3代表第34屆混沌通訊會議(Chaos Communication Congress)，是一個常年在德國舉辦的黑客聚會。

在本屆34C3大會上，活躍在開源EDA領域的Clifford Wolf發表了演講。當中提到了，在開源硬體領域，以RISC-V為代表，今年可以稱之為開源矽(Open Silicon)之年了。

演講中提到了Clifford在RISC-V形式驗證當中的一些工作。

If we were to pick one of the largest developments in the open-source hardware industry this year, we’d call 2017 the year of open silicon. In particular the open RISC-V processor came out in hardware that you can play around with now. In ten years, when we’re all running open-silicon “Arduinos”, remember this time. And if you haven’t been watching [Clifford Wolf], you might have missed that he wrote a 3D modelling software called openSCAD or a free FPGA toolchain, project Icestorm.

Link: 34C3: THE FIRST DAY IS A DOOZY

“Reflection On 2017”系列報道

Semiconductor Engineering的Brian Bailey發表了他對於2017年整個行業的思考，每一年他都會咨詢他的業界朋友們對新一年的預測，而在第二年的時候他又會讓他們去年的預測，看看哪些應驗了，而哪些又會讓人大吃一驚。

Schirrmeister預測2017對於微處理器行業來說會是很有趣的一年。這一年，MIPS在Imagination的交易中得以繼續，而RISC-V則吸引了大量的關註。越來越多的公司認可RISC-V並且有公司表明他們在做相關的開發工作。這一趨勢將會在2018年持續下去，這也讓一些傳統的廠商必須快速作出反應，就像Arm的非常的積極用DsignStart來對RISC-V作出反應一樣。

Schirrmeister also predicted that 2017 would be an interesting year for processor architectures. At that point he had said that “even Open Source hardware architectures are looking like they will be very relevant. It’s definitely one of the most entertaining spaces to watch in 2017 and for years to come.” He now responds. “The battle is raging and has resulted in some interesting new business models. MIPS has been spun out as part of the overall Imagination transition, and RISC-V certainly enjoys A LOT of attention with more companies endorsing it and announcing serious product developments for it. This trend will only accelerate in 2018 and has forced some of the traditional players to react fast—like Arm did with its Design Start initiative.

“The semiconductor industry witnessed a consolidation slowdown with new startups offering free, open solutions for today’s design challenges – not to mention established companies moving away from closed architectures,” adds Rick O’Connor, executive director of the RISC-V Foundation. “There is a growing interest in open-source instruction set architectures (ISAs), such as RISC-V. The portability and flexibility of the RISC-V architecture has driven innovation in a number of applications, addressing the increasing demands of our connected world from big data to the IoT. This newfound freedom in silicon design has also encouraged collaboration across the ecosystem by fostering a system-level approach to SoC design.

…

In fact, the RISC-V appears to be creating a lot of excitement. Rick O’Connor, executive director of the RISC-V Foundation, notes that “in 2017, the semiconductor industry witnessed a consolidation slowdown with new startups offering free, open solutions for today’s design challenges – not to mention established companies moving away from closed architectures. There is a growing interest in open-source instruction set architectures (ISAs), such as RISC-V. The portability and flexibility of the RISC-V architecture has driven innovation in a number of applications, addressing the increasing demands of our connected world from big data to the IoT. This newfound freedom in silicon design also has encouraged collaboration across the ecosystem by fostering a system-level approach to SoC design.”

Links:

CNRV網站更新

暴走事件

二月

招聘簡訊

CNRV提供為行業公司提供公益性質的一句話的招聘信息發布，若有任何Architecture、IC設計、軟體開發的招聘信息，歡迎聯系我們！

整理編集: 宋威、黃柏瑋、郭雄飛

歡迎關註微信公眾號CNRV，接收最新最時尚的RISC-V訊息！

CNRV微信公眾號

創用 CC 授權條款
本著作係採用創用 CC 姓名標示-非商業性-相同方式分享 3.0 台灣 授權條款授權.