diff --git a/bi-week-rpts/2018-12-25.md b/bi-week-rpts/2018-12-25.md
index d83b6db4..51891c73 100644
--- a/bi-week-rpts/2018-12-25.md
+++ b/bi-week-rpts/2018-12-25.md
@@ -52,6 +52,8 @@ Waterman 对此表示部分赞同。对于只支持的 Machine 和 User mode 的
 
 ## 代码更新
 
+HardenedLinux社区对于RISC-V硬件上运行[自由固件项目coreboot](http://coreboot.org/)的尝试开始于2017年，在HiFive1的[PoC](https://github.com/hardenedlinux/coreboot4HiFive1)成功后，我们在等待实际能运行GNU/Linux的硬件的同时也在研究基于RISC-V特权指令级v1.10版本的RV64架构，直到第一款能运行GNU/Linux的开发板HiFive Unleashed的发布，之后进行了[更多的测试](https://github.com/hardenedlinux/hardenedlinux_profiles/raw/master/slide/Firmware_Freedom-coreboot_for_RISC-V.pdf)。HiFive Unleashed的内存初始化代码公开后，完全开放并且可审计的blobless的自由固件成为了可能，此后HardenedLinux社区参与到了自由固件黑客们的工作中，到目前为止基础代码框架（DRAM/OTP/PHY初始化，异常处理，多核处理，SPI Flash初始化等）已经完成，更多的特性还在持续的推进到coreboot上游中，coreboot社区对类似x86的SMM并不喜欢，但安全加固中的enclave方案和固件运行时服务对于某些场景是刚需，未来可能会以BSD许可证的库来实现相关[payload](https://www.coreboot.org/Libpayload)。近日，HardenedLinux基于最新的社区版本[发布](https://twitter.com/hardenedlinux/status/1082208191419625473)了一个可以在HiFive Unleashed上运行GNU/Linux的[coreboot版本](https://github.com/hardenedlinux/coreboot-HiFiveUnleashed/tree/HiFive-Unleashed-Test-Change)，可以[参考文档](https://github.com/hardenedlinux/firmware-anatomy/tree/master/bin_blobs/hifive_unleashed)进行操作（[中文版](https://github.com/hardenedlinux/embedded-iot_profile/blob/master/docs/riscv/hifiveunleashed_coreboot_notes.md)）。
+
 ## 安全点评
 
 Keystone enclave于2018年12月[正式开源后](https://www.solidot.org/story?sid=58873)，其作者之一Dayeol Lee在[RISC-V Summit 2018上进行了详细的介绍](https://keystone-enclave.org/files/keystone-risc-v-summit.pdf)，Keystone enclave是基于早前的MIT Sanctum，对于Sanctum的软件部分做了很多扩充和改进使其通用性大幅度提升，但Keystone并没有考虑通用的[基于PUF/TRNG设计的RoT的部分](https://github.com/hardenedlinux/firmware-anatomy/blob/master/notes/sanctum.md)，信任根的方案Keystone目前只计划预留接口而非实现，这样一方面可以适配更多的RISC-V硬件平台，另外一方面也大大降低了工程复杂度可以让厂商在不修改硬件设计的情况下完成Enclave方案，而信任根作为可选部分直接沿用[Sanctum的的方案](https://content.riscv.org/wp-content/uploads/2018/12/16.30-Lebedev-Secure-Bootstrapping-of-Trusted-Software-in-RISC-V.pdf)，Enclave的基础页表管理依然是操作系统完成（跟SGX一样），由运行于M模式的安全监控器完成enclave的创建，操作系统可以请求安全监控器创建更多的enclave，而数量则受限于PMP的条目数，和常规enclave设计类似，异步退出必须由安全控制器的SBI call完成，而在执行enclave时进入未信任区域安全控制器会在之前改变权限。封闭的厂商实现[Intel SGX漏洞](https://hardenedlinux.github.io/system-security/2018/08/16/meltdown_spectre_l1tf.html)百出，我们需要更多像Sanctum/Keystone这样的开放且可审计的enclave方案。