diff --git a/assets/HTMFS_Strong_Consistency_Comes_for_Free_with_1682647018871_0.edn b/assets/HTMFS_Strong_Consistency_Comes_for_Free_with_1682647018871_0.edn index b35f5e0..42ca9a0 100644 --- a/assets/HTMFS_Strong_Consistency_Comes_for_Free_with_1682647018871_0.edn +++ b/assets/HTMFS_Strong_Consistency_Comes_for_Free_with_1682647018871_0.edn @@ -1602,4 +1602,4 @@ :page 14}, :content {:text " transaction semantics on PM"}, :properties {:color "yellow"}}], - :extra {:page 14}} + :extra {:page 12}} diff --git a/assets/XPC_Architectural_Support_for_Secure_and_Efficient_Cross_1682647057931_0.edn b/assets/XPC_Architectural_Support_for_Secure_and_Efficient_Cross_1682647057931_0.edn index d02a146..a0285e7 100644 --- a/assets/XPC_Architectural_Support_for_Secure_and_Efficient_Cross_1682647057931_0.edn +++ b/assets/XPC_Architectural_Support_for_Secure_and_Efficient_Cross_1682647057931_0.edn @@ -2791,4 +2791,4 @@ :page 13}, :content {:text "uses hardware capability pointers (which describe the lower and upper bounds of a memory range) for memory transfer."}, :properties {:color "yellow"}}], - :extra {:page 13}} + :extra {:page 11}} diff --git a/journals/2023_05_07.md b/journals/2023_05_07.md index e3946e1..95b7a33 100644 --- a/journals/2023_05_07.md +++ b/journals/2023_05_07.md @@ -1,5 +1,5 @@ - DONE Paper2 看完 - 废了我差不多一整天才看完 -- TODO 编译器调试 +- DONE 编译器调试 - 摆烂了,明天再说 - 明天又要上课了，无聊的小熊思想，无聊的中午课，还下雨，草 \ No newline at end of file diff --git a/journals/2023_05_08.md b/journals/2023_05_08.md new file mode 100644 index 0000000..15891a4 --- /dev/null +++ b/journals/2023_05_08.md @@ -0,0 +1,7 @@ +- DONE 写一下自我介绍 +- DONE 回顾论文，写个总结 +- TODO 写自我陈述初稿 +- DONE English resume refine + - TODO 扫描各种奖状：果酱证书、寻找robocup奖状、CET6扫描、成绩证明扫描 +- IPADS半夜发邮件是真的离谱，不让我好好睡觉了是吧 +- 调编译器浪费了比我预想中更多的时间，文书材料没写完，干 \ No newline at end of file diff --git a/journals/2023_05_09.md b/journals/2023_05_09.md new file mode 100644 index 0000000..0d1df94 --- /dev/null +++ b/journals/2023_05_09.md @@ -0,0 +1,3 @@ +- 明天要interview，只能写一天文书了，草 + - 再不写就要寄了 + - 姑且是差不多了 \ No newline at end of file diff --git a/journals/2023_05_10.md b/journals/2023_05_10.md new file mode 100644 index 0000000..0094935 --- /dev/null +++ b/journals/2023_05_10.md @@ -0,0 +1,3 @@ +- TODO 小熊思想读书会报告 +- TODO 跟学长要套磁信 +- TODO 写一会编译器，简单的llir生成 \ No newline at end of file diff --git a/logseq/bak/journals/2023_05_04/2023-05-08T02_32_16.559Z.Desktop.md b/logseq/bak/journals/2023_05_04/2023-05-08T02_32_16.559Z.Desktop.md new file mode 100644 index 0000000..3058a40 --- /dev/null +++ b/logseq/bak/journals/2023_05_04/2023-05-08T02_32_16.559Z.Desktop.md @@ -0,0 +1,3 @@ +- TODO Paper1-HTMFS Implementation 看完 +- TODO 模式识别作业提交 +- TODO 写一会编译器 \ No newline at end of file diff --git a/logseq/bak/journals/2023_05_07/2023-05-09T12_39_44.296Z.Desktop.md b/logseq/bak/journals/2023_05_07/2023-05-09T12_39_44.296Z.Desktop.md new file mode 100644 index 0000000..e3946e1 --- /dev/null +++ b/logseq/bak/journals/2023_05_07/2023-05-09T12_39_44.296Z.Desktop.md @@ -0,0 +1,5 @@ +- DONE Paper2 看完 + - 废了我差不多一整天才看完 +- TODO 编译器调试 + - 摆烂了,明天再说 +- 明天又要上课了，无聊的小熊思想，无聊的中午课，还下雨，草 \ No newline at end of file diff --git a/logseq/bak/journals/2023_05_08/2023-05-10T04_11_37.714Z.Desktop.md b/logseq/bak/journals/2023_05_08/2023-05-10T04_11_37.714Z.Desktop.md new file mode 100644 index 0000000..8968486 --- /dev/null +++ b/logseq/bak/journals/2023_05_08/2023-05-10T04_11_37.714Z.Desktop.md @@ -0,0 +1,7 @@ +- TODO 写一下自我介绍 +- TODO 回顾论文，写个总结 +- TODO 写自我陈述初稿 +- DONE English resume refine + - TODO 扫描各种奖状：果酱证书、寻找robocup奖状、CET6扫描、成绩证明扫描 +- IPADS半夜发邮件是真的离谱，不让我好好睡觉了是吧 +- 调编译器浪费了比我预想中更多的时间，文书材料没写完，干 \ No newline at end of file diff --git a/logseq/bak/pages/hls__HTMFS_Strong_Consistency_Comes_for_Free_with_1682647018871_0/2023-05-08T02_32_16.805Z.Desktop.md b/logseq/bak/pages/hls__HTMFS_Strong_Consistency_Comes_for_Free_with_1682647018871_0/2023-05-08T02_32_16.805Z.Desktop.md new file mode 100644 index 0000000..1f7147e --- /dev/null +++ b/logseq/bak/pages/hls__HTMFS_Strong_Consistency_Comes_for_Free_with_1682647018871_0/2023-05-08T02_32_16.805Z.Desktop.md @@ -0,0 +1,240 @@ +file:: [HTMFS_Strong_Consistency_Comes_for_Free_with_1682647018871_0.pdf](../assets/HTMFS_Strong_Consistency_Comes_for_Free_with_1682647018871_0.pdf) +file-path:: ../assets/HTMFS_Strong_Consistency_Comes_for_Free_with_1682647018871_0.pdf + +- Abstract + ls-type:: annotation + hl-page:: 2 + hl-color:: yellow + id:: 644b27f5-e3e1-4a24-a507-820e0abbbfd5 +- Introduction + ls-type:: annotation + hl-page:: 2 + hl-color:: yellow + id:: 644b2866-2f98-49f4-a914-2d1400d47e3b + - Earlier FSs optimize for performance, but provide loose consistency guarantees + - With the speedup of modern storage devices, strong consistency can ease the pain of software programming. + - Strong consistency implies per-request sequential consistency. + - atomic modification: inode level locks + - Transaction semantics after crash recovery, all-or-none + - modern storage devices, PMEM, or non-volatile RAM + hl-page:: 2 + ls-type:: annotation + id:: 64511829-234d-45a3-9d1c-f50d60466704 + hl-color:: yellow + - Problem with existent PM FS: complicated mechanism, write amplification + - Previous approaches are limited to atomicity unit of CPU writes. + ls-type:: annotation + hl-page:: 2 + hl-color:: yellow + id:: 64511979-cee9-4f46-87ba-6bbfe86bf0a4 + - Problem with RTM: Block IO abort RTM; PM can be accessed as RAM, but with cache involved, also abort RTM + - enhanced asynchronous DRAM refresh (eADR) + hl-page:: 3 + ls-type:: annotation + id:: 64511f4c-4338-41ad-9264-263ed5a08bf4 + hl-color:: yellow + - guarantee the persistence of memory writes once they become globally visible, + ls-type:: annotation + hl-page:: 3 + hl-color:: yellow + id:: 6451204b-d1b8-46ed-8ec9-3a7c2d05244e + - eliminate the need for cache flush to sync with PM + - See [Detail](https://www.intel.com/content/www/us/en/developer/articles/technical/eadr-new-opportunities-for-persistent-memory-applications.html) + - Several challenges with RTM-PM + hl-page:: 3 + ls-type:: annotation + id:: 6451205e-7f48-43e8-8704-d221d806cc18 + hl-color:: yellow + - RTM is small, while FS data transfer are generally large + - Some FS operations have long code-path, lengthening RTM section, increasing conflict abort rate + - Hardware-assisted Optimistic Persistence + ls-type:: annotation + hl-page:: 3 + hl-color:: yellow + id:: 64512109-8ab0-49aa-b6a3-1524df0631ef + - eADR, HTM with cooperative locks as fallback + - HTMFS, a user-space PM file systems base on ZoFS + ls-type:: annotation + hl-page:: 3 + hl-color:: yellow + id:: 64512150-84a0-4839-aef6-48bb872fa776 +- Background and Motivation + ls-type:: annotation + hl-page:: 3 + hl-color:: yellow + id:: 6451215b-a495-4d6f-9427-f5c0c6685a28 + - Persistent Memory and PM File Systems + ls-type:: annotation + hl-page:: 4 + hl-color:: yellow + id:: 645124e7-37ae-404c-bc83-2ae78628767f + - 主要的点就是，PM 是 ==byte-addressable== + - Existing PMFS: The only difference would be leveraging atomic instructions to provide small updates up to a single cache line + hl-page:: 4 + ls-type:: annotation + id:: 64526ec1-37e2-4891-bba8-eeb07c6e02d3 + hl-color:: yellow + - 作者认为现有的PMFS没啥创新，在一致性上还是用的旧东西，除了用 PM 提供的 atomic inst 来简化某些原子操作 + - 2.3 Hardware Transactional Memory + ls-type:: annotation + hl-page:: 4 + hl-color:: yellow + id:: 6452709d-6036-4dcd-8821-c106562565fe + - RTM的基本用法：把 critical section 用 `xbegin` 和 `xend` 包起来 + hl-page:: 4 + ls-type:: annotation + id:: 645270e0-2153-4414-8b22-762cfc113c19 + hl-color:: yellow + - Conflict aborts + hl-page:: 4 + ls-type:: annotation + id:: 64527149-e50e-46c8-990f-0465060f9a5a + hl-color:: yellow + - 硬件维护trx的 read set 和 write set，如果在提交之前，有别的 core 读 write set 或者写 read set，就会 abort。这些东西都在 cache 里面，维护这些也是用 cache coherence protocol + - Capacity aborts. + ls-type:: annotation + hl-page:: 4 + hl-color:: yellow + id:: 645271fa-ff04-4263-a2f2-d1879c1fb857 + - 受到每个core本地cache比如L1，的大小的限制 + - Other aborts + hl-page:: 4 + ls-type:: annotation + id:: 64527248-77dc-4d32-8a2b-737b7329d2e9 + hl-color:: yellow + - 不兼容指令，中断（所以打IO显然不行）等东西 + - 2.4 HTM in PM File Systems + ls-type:: annotation + hl-page:: 4 + hl-color:: yellow + id:: 64527270-d6d5-4232-98af-c0212ef47511 + - HTM的操作是在 cache 里面的，没有持久化保证，除非显式刷到内存/PM里。但是 临界区内不能刷（刷了就abort），临界区之后要是被切走就寄了（除非上锁，不如直接上锁） + - Intel 的新东西表示，它可以做到commit到cache里面就能持久化 +- 3 Design + ls-type:: annotation + hl-page:: 5 + hl-color:: yellow + id:: 6452774e-a951-480a-a890-322d30fe3fd0 + - 直接把 FS 操作用HTM包起来不现实，因为FS的操作都很长很大 + - 3.1 HOP + ls-type:: annotation + hl-page:: 5 + hl-color:: yellow + id:: 645277dc-272c-4479-9d09-3f178cb77a42 + - 非常自然的想法：把一个操作，或者说trx，拆成小的 + - 三种操作分类： + - Read、Invisible write(内部的东西，比如块分配信息) 、Visible write(应用程序可见的) + - 只有 Visible Write 用 HTM 实现，Invisible 和 Read 通过别的机制来实现 + - （对于一整个FS操作）首先在 RTM 外面完成所需的 read 和 invisible，然后用 RTM 完成 visible，保证它们是 atomic 的。 + hl-page:: 5 + ls-type:: annotation + id:: 64533b91-7e2b-448b-bb4f-807cc7cb5a77 + hl-color:: yellow + - RTM外面的部分不保证并发安全，用 sequence count 来解决这个问题。 + hl-page:: 5 + ls-type:: annotation + id:: 64533cf1-c232-4630-8cf9-88cf4dbfe0c2 + hl-color:: yellow + - 这东西的原型是 Linux 里面的 `seqlock` 。基本原理可以看这个。 [SeqLock中文博客](http://www.wowotech.net/kernel_synchronization/seqlock.html)。 然后这里的机制大概就是把 writer lock 给换成了 RTM，虽然细节上不是很一样 + - 在读之前（RTM外）先记录 seqcount，然后进入 RTM 之后进行验证，需要保证在 RTM commit 之前这些 seqcount 都没变。如果有变化，就需要重新回到 RTM 外面的某一点重新读取 + - 当然如果是 accidental abort，那么只需要重新执行RTM就可以了（就算前面读的数据炸了，反正还是要验证一次的） + - 不过有个问题它没说，就是 invisible write，它没有RTM保证不会写冲突啊？不过也有可能，它会保证 invisible 不涉及临界区？？ + - Discussion of concurrency correctness. + ls-type:: annotation + hl-page:: 5 + hl-color:: yellow + id:: 6453427e-ce5a-4746-960b-45f9546e8b37 + - Read-Read显然不冲突 + - Write-Write 他说potential conflicting write 会被RTM保护起来，不过有可能会live lock掉 + - Write-Read 也就是如果在RTM里面写入并且commit之前读取，会导致RTM abort + - Read-Write 的情况就比较复杂了。作者给了个图，考虑了 T1 读，同时有T2写的例子 + - T2 在 T1 验证之前写：Valid fail 然后重新读。不过其实是有一个 overlap 的，图里面的第三个B点应该也会 RTM-abort + - T2 在 T1 验证之后、RTM commit 之前写：因为读取的数据在 RTM 的 read-set 里面，所有还是会 RTM abort +- 3.2 File Operations + ls-type:: annotation + hl-page:: 6 + hl-color:: yellow + id:: 64534050-8459-4719-866e-612b76560e00 + - 其实看 Figure 3 就行了 + - 3.2.1 Data Read + ls-type:: annotation + hl-page:: 6 + hl-color:: yellow + id:: 64534bc6-4bde-47c6-9fa2-3a085ff59c66 + - 前面也写了，用 seqcnt 机制来保证读一致性。众所周知，每个文件的inode里面都有block指针，这里给每个指针都配上了一个seqno，读的时候就用这些个东西 + - 3.2.2 Data Write + ls-type:: annotation + hl-page:: 6 + hl-color:: yellow + id:: 64534cee-e35f-4e07-a79d-9185e36b57a2 + - convert data updates to metadata updates that can be embedded in the RTM transactions. + ls-type:: annotation + hl-page:: 6 + hl-color:: yellow + id:: 645357b1-b9ab-456c-87b3-c1047ec5ce59 + - small writes，直接塞进RTM + hl-page:: 6 + ls-type:: annotation + id:: 64535855-08bc-484d-951e-6cf191d5729f + hl-color:: yellow + - 大量写入，先把数据写入PM，然后再更新元数据。这时候用的就是block指针了。具体：空间分配是用的DRAM数据；（存疑？然后 shadow page 写文件数据）；最后 RTM 修改 FS 元数据，allocation 的修改这个时候才会被持久化。如果 trx 提交之前炸了，顶多就是写了点垃圾数据到空白位置罢了。 + - But the blocks may have leaked after a system crash. 没看懂，为啥会leak啊？你的 alloc 数据又没落盘。 + hl-stamp:: 1683184901505 + hl-page:: 6 + ls-type:: annotation + id:: 64535ce3-9927-4e22-b2ed-9c396c3b43f2 + hl-color:: red + - 不过看上去，它们这边是认为分配一个块是个双向的过程，不仅会在总的freelist里面有记录，block 里面也有一个记录表明它的分配情况？ + - 3.2.3 Allocation + ls-type:: annotation + hl-page:: 7 + hl-color:: yellow + id:: 64534d02-3d6b-4dd4-8d3f-e86767190f08 + - 首先把已经分配的块放进一个 temporal allocating list 里面 （大概会在 alloc 阶段持久化？），如果commit成功就不管它，如果出事了就把这个里面的块还回去 + hl-page:: 7 + ls-type:: annotation + id:: 64535d27-c876-4481-856e-8962e5ba9b16 + hl-color:: yellow + - 在释放块的时候，也会存在中途 crash 的问题。一般是先删掉reference 然后再释放块，如果没释放完，那这个块就leak了。还是有和前面类似的疑问，这东西不是 引用一删就已经整完了吗？ + - the file system crashes after a reference to a block of data has been removed (when this block of memory has not yet been freed) + ls-type:: annotation + hl-page:: 7 + hl-color:: red + id:: 64535f97-b733-4522-a2d1-dbfc8837799e + hl-stamp:: 1683185566331 +- 3.3 Directory Operations + ls-type:: annotation + hl-page:: 7 + hl-color:: yellow + id:: 64534d0c-9fe2-4817-b510-5d2da7d55dbf + - 3.3.1 Path Walk + ls-type:: annotation + hl-page:: 7 + hl-color:: yellow + id:: 64534d0f-1882-4633-9cd4-fce9d411aeb9 + - 3.3.2 Directory Updates + ls-type:: annotation + hl-page:: 7 + hl-color:: yellow + id:: 64534d19-b941-4c04-a084-2d8a09d00883 +- 3.4 Other File Types + ls-type:: annotation + hl-page:: 8 + hl-color:: yellow + id:: 64534d23-1327-40ef-b58e-7c5a01559552 + - 就写了一个 symlink，但是这玩意就是其他操作的组合罢了，没啥特别的东西 +- 3.5 The Timestamps + ls-type:: annotation + hl-page:: 8 + hl-color:: yellow + id:: 64534d33-2bfe-4817-a5bd-0cc3534584d7 +- 3.6 The Special Case: Rename + ls-type:: annotation + hl-page:: 8 + hl-color:: yellow + id:: 64534d37-b14f-4943-92c0-7bb4823fbd50 +- 4 Implementation + ls-type:: annotation + hl-page:: 9 + hl-color:: yellow + id:: 64534d45-e498-427d-b4ef-74eaf56f7aae \ No newline at end of file diff --git a/logseq/bak/pages/hls__HTMFS_Strong_Consistency_Comes_for_Free_with_1682647018871_0/2023-05-09T12_39_44.382Z.Desktop.md b/logseq/bak/pages/hls__HTMFS_Strong_Consistency_Comes_for_Free_with_1682647018871_0/2023-05-09T12_39_44.382Z.Desktop.md new file mode 100644 index 0000000..a21f246 --- /dev/null +++ b/logseq/bak/pages/hls__HTMFS_Strong_Consistency_Comes_for_Free_with_1682647018871_0/2023-05-09T12_39_44.382Z.Desktop.md @@ -0,0 +1,456 @@ +file:: [HTMFS_Strong_Consistency_Comes_for_Free_with_1682647018871_0.pdf](../assets/HTMFS_Strong_Consistency_Comes_for_Free_with_1682647018871_0.pdf) +file-path:: ../assets/HTMFS_Strong_Consistency_Comes_for_Free_with_1682647018871_0.pdf + +- Abstract + ls-type:: annotation + hl-page:: 2 + hl-color:: yellow + id:: 644b27f5-e3e1-4a24-a507-820e0abbbfd5 +- Introduction + ls-type:: annotation + hl-page:: 2 + hl-color:: yellow + id:: 644b2866-2f98-49f4-a914-2d1400d47e3b + - Earlier FSs optimize for performance, but provide loose consistency guarantees + - With the speedup of modern storage devices, strong consistency can ease the pain of software programming. + - Strong consistency implies per-request sequential consistency. + - atomic modification: inode level locks + - Transaction semantics after crash recovery, all-or-none + - modern storage devices, PMEM, or non-volatile RAM + hl-page:: 2 + ls-type:: annotation + id:: 64511829-234d-45a3-9d1c-f50d60466704 + hl-color:: yellow + - Problem with existent PM FS: complicated mechanism, write amplification + - Previous approaches are limited to atomicity unit of CPU writes. + ls-type:: annotation + hl-page:: 2 + hl-color:: yellow + id:: 64511979-cee9-4f46-87ba-6bbfe86bf0a4 + - Problem with RTM: Block IO abort RTM; PM can be accessed as RAM, but with cache involved, also abort RTM + - enhanced asynchronous DRAM refresh (eADR) + hl-page:: 3 + ls-type:: annotation + id:: 64511f4c-4338-41ad-9264-263ed5a08bf4 + hl-color:: yellow + - guarantee the persistence of memory writes once they become globally visible, + ls-type:: annotation + hl-page:: 3 + hl-color:: yellow + id:: 6451204b-d1b8-46ed-8ec9-3a7c2d05244e + - eliminate the need for cache flush to sync with PM + - See [Detail](https://www.intel.com/content/www/us/en/developer/articles/technical/eadr-new-opportunities-for-persistent-memory-applications.html) + - Several challenges with RTM-PM + hl-page:: 3 + ls-type:: annotation + id:: 6451205e-7f48-43e8-8704-d221d806cc18 + hl-color:: yellow + - RTM is small, while FS data transfer are generally large + - Some FS operations have long code-path, lengthening RTM section, increasing conflict abort rate + - Hardware-assisted Optimistic Persistence + ls-type:: annotation + hl-page:: 3 + hl-color:: yellow + id:: 64512109-8ab0-49aa-b6a3-1524df0631ef + - eADR, HTM with cooperative locks as fallback + - HTMFS, a user-space PM file systems base on ZoFS + ls-type:: annotation + hl-page:: 3 + hl-color:: yellow + id:: 64512150-84a0-4839-aef6-48bb872fa776 +- Background and Motivation + ls-type:: annotation + hl-page:: 3 + hl-color:: yellow + id:: 6451215b-a495-4d6f-9427-f5c0c6685a28 + - Persistent Memory and PM File Systems + ls-type:: annotation + hl-page:: 4 + hl-color:: yellow + id:: 645124e7-37ae-404c-bc83-2ae78628767f + - 主要的点就是，PM 是 ==byte-addressable== + - Existing PMFS: The only difference would be leveraging atomic instructions to provide small updates up to a single cache line + hl-page:: 4 + ls-type:: annotation + id:: 64526ec1-37e2-4891-bba8-eeb07c6e02d3 + hl-color:: yellow + - 作者认为现有的PMFS没啥创新，在一致性上还是用的旧东西，除了用 PM 提供的 atomic inst 来简化某些原子操作 + - 2.3 Hardware Transactional Memory + ls-type:: annotation + hl-page:: 4 + hl-color:: yellow + id:: 6452709d-6036-4dcd-8821-c106562565fe + - RTM的基本用法：把 critical section 用 `xbegin` 和 `xend` 包起来 + hl-page:: 4 + ls-type:: annotation + id:: 645270e0-2153-4414-8b22-762cfc113c19 + hl-color:: yellow + - Conflict aborts + hl-page:: 4 + ls-type:: annotation + id:: 64527149-e50e-46c8-990f-0465060f9a5a + hl-color:: yellow + - 硬件维护trx的 read set 和 write set，如果在提交之前，有别的 core 读 write set 或者写 read set，就会 abort。这些东西都在 cache 里面，维护这些也是用 cache coherence protocol + - Capacity aborts. + ls-type:: annotation + hl-page:: 4 + hl-color:: yellow + id:: 645271fa-ff04-4263-a2f2-d1879c1fb857 + - 受到每个core本地cache比如L1，的大小的限制 + - Other aborts + hl-page:: 4 + ls-type:: annotation + id:: 64527248-77dc-4d32-8a2b-737b7329d2e9 + hl-color:: yellow + - 不兼容指令，中断（所以打IO显然不行）等东西 + - 2.4 HTM in PM File Systems + ls-type:: annotation + hl-page:: 4 + hl-color:: yellow + id:: 64527270-d6d5-4232-98af-c0212ef47511 + - HTM的操作是在 cache 里面的，没有持久化保证，除非显式刷到内存/PM里。但是 临界区内不能刷（刷了就abort），临界区之后要是被切走就寄了（除非上锁，不如直接上锁） + - Intel 的新东西表示，它可以做到commit到cache里面就能持久化 +- 3 Design + ls-type:: annotation + hl-page:: 5 + hl-color:: yellow + id:: 6452774e-a951-480a-a890-322d30fe3fd0 + - 直接把 FS 操作用HTM包起来不现实，因为FS的操作都很长很大 + - 3.1 HOP + ls-type:: annotation + hl-page:: 5 + hl-color:: yellow + id:: 645277dc-272c-4479-9d09-3f178cb77a42 + - 非常自然的想法：把一个操作，或者说trx，拆成小的 + - 三种操作分类： + - Read、Invisible write(内部的东西，比如块分配信息) 、Visible write(应用程序可见的) + - 只有 Visible Write 用 HTM 实现，Invisible 和 Read 通过别的机制来实现 + - （对于一整个FS操作）首先在 RTM 外面完成所需的 read 和 invisible，然后用 RTM 完成 visible，保证它们是 atomic 的。 + hl-page:: 5 + ls-type:: annotation + id:: 64533b91-7e2b-448b-bb4f-807cc7cb5a77 + hl-color:: yellow + - RTM外面的部分不保证并发安全，用 sequence count 来解决这个问题。 + hl-page:: 5 + ls-type:: annotation + id:: 64533cf1-c232-4630-8cf9-88cf4dbfe0c2 + hl-color:: yellow + - 这东西的原型是 Linux 里面的 `seqlock` 。基本原理可以看这个。 [SeqLock中文博客](http://www.wowotech.net/kernel_synchronization/seqlock.html)。 然后这里的机制大概就是把 writer lock 给换成了 RTM，虽然细节上不是很一样 + - 在读之前（RTM外）先记录 seqcount，然后进入 RTM 之后进行验证，需要保证在 RTM commit 之前这些 seqcount 都没变。如果有变化，就需要重新回到 RTM 外面的某一点重新读取 + - 当然如果是 accidental abort，那么只需要重新执行RTM就可以了（就算前面读的数据炸了，反正还是要验证一次的） + - 不过有个问题它没说，就是 invisible write，它没有RTM保证不会写冲突啊？不过也有可能，它会保证 invisible 不涉及临界区？？ + - Discussion of concurrency correctness. + ls-type:: annotation + hl-page:: 5 + hl-color:: yellow + id:: 6453427e-ce5a-4746-960b-45f9546e8b37 + - Read-Read显然不冲突 + - Write-Write 他说potential conflicting write 会被RTM保护起来，不过有可能会live lock掉 + - Write-Read 也就是如果在RTM里面写入并且commit之前读取，会导致RTM abort + - Read-Write 的情况就比较复杂了。作者给了个图，考虑了 T1 读，同时有T2写的例子 + - T2 在 T1 验证之前写：Valid fail 然后重新读。不过其实是有一个 overlap 的，图里面的第三个B点应该也会 RTM-abort + - T2 在 T1 验证之后、RTM commit 之前写：因为SeqCnt在 RTM 的 read-set 里面，写操作会修改seqcnt，所有还是会 RTM abort +- 3.2 File Operations + ls-type:: annotation + hl-page:: 6 + hl-color:: yellow + id:: 64534050-8459-4719-866e-612b76560e00 + - 其实看 Figure 3 就行了。首先分配 shadow page，然后写 shadow page，最后用 RTM 更新指针到 shadow 上。 + - 3.2.1 Data Read + ls-type:: annotation + hl-page:: 6 + hl-color:: yellow + id:: 64534bc6-4bde-47c6-9fa2-3a085ff59c66 + - 前面也写了，用 seqcnt 机制来保证读一致性。众所周知，每个文件的inode里面都有block指针，这里给每个指针都配上了一个seqno，读的时候就用这些个东西 + - 3.2.2 Data Write + ls-type:: annotation + hl-page:: 6 + hl-color:: yellow + id:: 64534cee-e35f-4e07-a79d-9185e36b57a2 + - convert data updates to metadata updates that can be embedded in the RTM transactions. + ls-type:: annotation + hl-page:: 6 + hl-color:: yellow + id:: 645357b1-b9ab-456c-87b3-c1047ec5ce59 + - small writes，直接塞进RTM + hl-page:: 6 + ls-type:: annotation + id:: 64535855-08bc-484d-951e-6cf191d5729f + hl-color:: yellow + - 大量写入，先把数据写入PM，然后再更新元数据。这时候用的就是block指针了。具体：空间分配是用的DRAM数据；（存疑？然后 shadow page 写文件数据）；最后 RTM 修改 FS 元数据，allocation 的修改这个时候才会被持久化。如果 trx 提交之前炸了，顶多就是写了点垃圾数据到空白位置罢了。 + - But the blocks may have leaked after a system crash. 没看懂，为啥会leak啊？你的 alloc 数据又没落盘。 + hl-stamp:: 1683184901505 + hl-page:: 6 + ls-type:: annotation + id:: 64535ce3-9927-4e22-b2ed-9c396c3b43f2 + hl-color:: red + - 不过看上去，它们这边是认为分配一个块是个双向的过程，不仅会在总的freelist里面有记录，block 里面也有一个记录表明它的分配情况？ + - 3.2.3 Allocation + ls-type:: annotation + hl-page:: 7 + hl-color:: yellow + id:: 64534d02-3d6b-4dd4-8d3f-e86767190f08 + - 首先把已经分配的块放进一个 temporal allocating list 里面 （大概会在 alloc 阶段持久化？），如果commit成功就不管它，如果出事了就把这个里面的块还回去 + hl-page:: 7 + ls-type:: annotation + id:: 64535d27-c876-4481-856e-8962e5ba9b16 + hl-color:: yellow + - 在释放块的时候，也会存在中途 crash 的问题。一般是先删掉reference 然后再释放块，如果没释放完，那这个块就leak了。还是有和前面类似的疑问，这东西不是 引用一删就已经整完了吗？ + - the file system crashes after a reference to a block of data has been removed (when this block of memory has not yet been freed) + ls-type:: annotation + hl-page:: 7 + hl-color:: red + id:: 64535f97-b733-4522-a2d1-dbfc8837799e + hl-stamp:: 1683185566331 + - 反正感觉讲的就挺矛盾的。。。也有可能是没理解清楚？ +- 3.3 Directory Operations + ls-type:: annotation + hl-page:: 7 + hl-color:: yellow + id:: 64534d0c-9fe2-4817-b510-5d2da7d55dbf + - Figure 5 描述了目录的形式。相较于简单的UNIX FS，它在目录的inode和entry之间加了一个hash table。DirInode 指向一个 block 里面放了一个hash tab， 然后每个hash tab entry指向一组dir entries，里面才是每个目录的名字、inode + - 3.3.1 Path Walk + ls-type:: annotation + hl-page:: 7 + hl-color:: yellow + id:: 64534d0f-1882-4633-9cd4-fce9d411aeb9 + - 记录每个遍历到的entry的seqcnt，然后在RTM里面验证这些家伙 + hl-page:: 7 + ls-type:: annotation + id:: 645385d6-70be-41ba-8697-f6bf49608834 + hl-color:: yellow + - 3.3.2 Directory Updates + ls-type:: annotation + hl-page:: 7 + hl-color:: yellow + id:: 64534d19-b941-4c04-a084-2d8a09d00883 + - 不对目录的inode加锁。 + - 插入或删除Dir Entry 的时候，更新 hash tab 的 bucket 的 Bseq，这样就不会冲突了（甚至还能增加一些并行性能，如果hash到不同的bucket）。不过好像直接用正在修改的目录的 Dseq 好像也可以？ +- 3.4 Other File Types + ls-type:: annotation + hl-page:: 8 + hl-color:: yellow + id:: 64534d23-1327-40ef-b58e-7c5a01559552 + - 就写了一个 symlink，但是这玩意就是其他操作的组合罢了，没啥特别的东西 +- 3.5 The Timestamps + ls-type:: annotation + hl-page:: 8 + hl-color:: yellow + id:: 64534d33-2bfe-4817-a5bd-0cc3534584d7 + - 三种 timestamp： Access（访问）, Modified（修改内容）, Changed（修改元数据） + - timestamp应该和其他操作写在同一个 trx 里面 + - Here we observe that placing accesses and modifications to critical variables at the end of a transaction significantly reduces the probability of an abort due to conflicts. + ls-type:: annotation + hl-page:: 8 + hl-color:: yellow + id:: 6453916b-6fc1-4e3a-8e54-5d6c3767cf45 + - 不知道为啥 +- 3.6 The Special Case: Rename + ls-type:: annotation + hl-page:: 8 + hl-color:: yellow + id:: 64534d37-b14f-4943-92c0-7bb4823fbd50 + - `unlink` 和 `rmdir` 都只能删掉叶子节点，比如 rm 只能删掉空目录，所以比较简单 + - `rename` 操作没有限制，会涉及到两条路径，要删一个entry再加一条entry + - 可能的死锁问题，两个并发的rename操作，涉及相同的两个目录，然后互相锁了一个。可以通过比较 lock 变量地址的方法来决定上锁顺序以避免这个问题 + - 目录环问题。paper里面的例子讲的很清楚，只锁两个父目录没用，虽然不会出现一致性问题，但是会出环。所以一般会用个全局锁 + - 不过 HOP 不会有这个问题。因为它的目录依赖都被记录了，只要有任何一级目录被修改，都会 validation fail 然后重来。在RTM里面会进行：validate、 removing 和 adding 三个操作 +- 4 Implementation + ls-type:: annotation + hl-page:: 9 + hl-color:: yellow + id:: 64534d45-e498-427d-b4ef-74eaf56f7aae + - 基于 ZoFS 实现，不过我也不知道它是个啥。它分成两部分，内核里面一部分，还有用户空间的 Library。 + - 坏家伙，ZoFS 是也是这帮人自己写的 + - 根据权限不同，把整个 FS tree 分成不同的 zone + - Figure 7： HTMFS 分为 KernFS （大概是直接白嫖了 ZoFS 的）和自己写的 LibFS。两者通过接口 `Coffer_enlarge/shrink` 进行交互，好像 KernFS 就是个分配管理器。。。。 + - 4.1 KernFS + ls-type:: annotation + hl-page:: 9 + hl-color:: yellow + id:: 64539829-6f23-49fe-a860-ffa78b301acd + - 维护整个 FS 所有 zone 的信息，以及 PM 页面的属性 + - 每个 zone 有一个 root page 存元数据 + - 用一个 persistent 哈希表存所有的 zone ，映射 zone 的路径前缀 -> zone 的 root page 的相对地址 + - User space 的请求发过来是路径，然后 KernFS 通过这个表获得 zone + - 两级分配：把很多的 pages 分给 zone，然后每个 zone 在细分管理这些 page。 + - KernFS 会管理这些页面的分配状态。用两个全局的红黑树来管理 free 和 allocated 的空间，这两颗 RBT 在DRAM里面， crash 之后需要重建 +- 4.2 LibFS + ls-type:: annotation + hl-page:: 9 + hl-color:: yellow + id:: 6453982f-f915-40ae-a87b-f94a89af4369 + - 维护每个 zone 内部的 data metadata，比如文件、目录 + - 前面的 Design 都是在这里实现的 + - KernFS 用 free list 管理分配，如果某个 zone 打 syscall 请求空间， KernFS 返回一个 free list 。为了不修改 kernel side， LibFS 要转换这个 list 使得能够被 HTMFS 识别 + - Fallback path ：先 retry 再上锁（+ RTM 更新）最后 journaling + hl-page:: 9 + ls-type:: annotation + id:: 6453a07f-ca96-4a02-9cc3-1c4cb460ebee + hl-color:: yellow + - 因为有这个 fallback ，所以在 RTM 里面要先检查是不是别的进程给 lock 了，如果 lock 了就直接中止 RTM 转而去抢 lock 。 + - 总结一个 RTM trick ：如果要检查什么东西，放进 RTM 里面检查，因为会加进 read-set ，这样别人改了的话就会 abort +- 4.3 Prevent RTM abort + ls-type:: annotation + hl-page:: 9 + hl-color:: yellow + id:: 64539833-3b3c-451b-b550-6d33dd8ac106 + - 主要原因是 page fault ，但是没法搞，所以事先 access 一下，然后再进 RTM，这样就不太容易在 RTM 里面炸了 + - 偶然的 abort，直接 retry ；如果次数太多，那么就 fallback + - fallback 策略：先上锁，把 conflict abort 的可能性消除，然后再执行 HOP （或者说是RTM，就是前面的机制，这里只是不让他们冲突了）来保证崩溃一致性 + - 其他原因，什么指令问题，不过那个链接挂了 +- 5 Evaluation + ls-type:: annotation + hl-page:: 10 + hl-color:: yellow + id:: 64551435-bee3-456a-93f1-8fce14cd5771 + - Performance comparison with weak consistency FS + - Application performance + - How HTM improve FS +- 5.2 Micro-benchmarks + ls-type:: annotation + hl-page:: 10 + hl-color:: yellow + id:: 64551575-289f-4811-9a35-863dbe0a0eb7 + - Data overwrite, low contention, first 4K of ==Different files== + - `rep-mov` 和 `sse-mov` 之间的性能差距导致 HTMFS 比 ZoFS 要慢 + - 在这种情况下，cache hit rate 很高。而 `rep-mov` 的性能在这种情况下 `sse2-mov` 要好。其他的没有这种问题（因为hit） + - Data overwrite, medium contention. ==Shared file, different blocks== + - lock-free 让 HTMFS 在这种情况下显著领先，而其他的FS会随着并发数上升而性能下降 + - Scalability + - Data append, low contention + - most writes miss the cache + ls-type:: annotation + hl-page:: 10 + hl-color:: yellow + id:: 64551b25-e4a7-401d-b143-3d4857c4e294 + - NOVA 用了 non-temporal write 和 per-core allocator，绕过 cache 直接写 PM + - HTMFS 正常先写 cache 然后再同步到 PM，miss 的时候要先读再写（占两倍带宽），导致 PM 的带宽不够了 + - 如果给 HTMFS 换上 NT write ，性能会好很多 + - 好像后面还是会寄掉，说是撞到了 bandwidth 上限 + - Data read, low contention. Different file, a block + - all file systems scale nearly linearly （虽然HTMFS更高） + hl-page:: 10 + ls-type:: annotation + id:: 64551cee-971e-4759-be45-8f96ebe50a4e + hl-color:: yellow + - medium, high contention 的情况 (shared file/shared block) 差不多 + - Metadata create. Create files in different directories + - 到后面不 scale 了，写入带宽不够 + - NOVA 在低带宽的情况下比 HTMFS 好，因为 ZoFS 用 0 表示不存在的页面，因此在创建的时候要大量写0，而 ZoFS 没有很好的 crash consistency，如果仅用文件大小表示页面存在性，可能会导致 index 和 size 不一致 + - 如果 HTMFS 删掉这个步骤（有一致性保证）变成 NZ 版本，会变快跟NOVA差不多 + - Metadata create, medium. Create files in same directory. + - HTMFS scales best. 因为用的锁策略是 hash bucket + - NZ 效果前期会更好，因为消除了一些 memset + - Metadata rename, low. Rename in different dirs + - All scale linearly, HTMFS best + - Metadata rename, medium. Move to shared dir + - HTMFS much better, fine-grained OCC + - Abort rate. + ls-type:: annotation + hl-page:: 11 + hl-color:: yellow + id:: 64551ead-5c0e-4978-99f6-f9156e8ed99e + - 基本上没什么，到 Fall back 的就更少了 + - The latency of the fallback path. + ls-type:: annotation + hl-page:: 11 + hl-color:: yellow + id:: 64551ef9-fa99-4c2d-8dd5-e0343042aeb6 + - 3 paths, HTM, fallback, journal + - Data write 的延迟，fallback 略高于 HTM，但是 journal 远高于 两倍的HTM + - 这是因为 HTM 不是直接写 PM 的，而是写 cache （然后由 eADR 保证断电后 cache 的东西会存进 PM）。如果用直接写 PM 的方法，那么 journal 差不多是两倍 + - Metadata write 的延迟几种差不多 + - The performance under high abort rate. Write same file same block + ls-type:: annotation + hl-page:: 12 + hl-color:: yellow + id:: 645522ec-84b5-4c1e-b029-90cb01e58587 + - 测试的是 fallback 的性能，如果不是由于 memcpy 指令，HTMFS 的性能最好 +- 5.3 Macro-benchmarks + ls-type:: annotation + hl-page:: 12 + hl-color:: yellow + id:: 64551608-5fe1-4f1b-adfc-6d13f0226c41 + - 用了两个综合测试。都是小文件读写 + - Webproxy 是读为主，几种好像都差不多，HTMFS和ZoFS稍微高一点 + - Varmail 是读写差不多，metadata操作多，HTMFS比较好 +- 5.4 Crash Consistency Correctness + ls-type:: annotation + hl-page:: 12 + hl-color:: yellow + id:: 6455164b-8ba7-4bef-b5d8-bb59aca3db00 + - 论文里面写了一个例子。给一个 4KB 的 全a文件写8KB的b字符。 + - 先分配一个4K空页 + - fill 0-4l + - fill 4k-8k + - 把4K页更新进file index + - 更新文件大小和修改时间 + - 参考状态是 all-or-nothing，也就是要么4K的a；要么8K的b同时修改时间更新、freelist减少 + - 在表里面，展示了1之后crash、2之后crash、5中间crash三种 crash injection +- 5.5 Application Benchmarks + ls-type:: annotation + hl-page:: 12 + hl-color:: yellow + id:: 64551652-fb9f-4e40-863f-96e5e3b40ef7 + - SQLite + TPC-C + - 测吞吐量 + - HTMFS/ZoFS(相当于是HTMFS的弱一致版本)性能最好，而且HTMFS相对于ZoFS的性能损失较小 + - NOVA的强一致和弱一致版本之间的差距较大 + - LevelDB + - 测延时 + - NOVA的写延时要比HTMFS好，而读要差一些 + - HTMFS和ZoFS性能几乎一致，而NOVA的弱一致版本则在写性能上有较大差距，说明一致性代价较大 +- 6 Discussion + ls-type:: annotation + hl-page:: 13 + hl-color:: yellow + id:: 6455165b-d35d-4532-beeb-320e353e49ce + - 6.1 Other File System Features + ls-type:: annotation + hl-page:: 13 + hl-color:: yellow + id:: 64552664-0fc7-426a-bfea-94d9833ef8a8 + - Compression, Deduplication, Checksum + - 这些操作基本上都没有对基本的FS操作提出特殊的要求 + - 6.2 HOP in Key-Value Stores + ls-type:: annotation + hl-page:: 14 + hl-color:: yellow + id:: 645526bd-e94d-4728-8180-2fcdacffc711 + - HOP 机制可以迁移到 KV 数据库上 +- 7 Related Work + ls-type:: annotation + hl-page:: 14 + hl-color:: yellow + id:: 645516e6-8343-4d4e-9f2c-f6c13d13687d + - Persistent Transactions. + ls-type:: annotation + hl-page:: 14 + hl-color:: yellow + id:: 64552bd5-b559-4a64-b2e5-053111a4ebdd + - transaction semantics on PM, software programming, user-space + hl-page:: 14 + ls-type:: annotation + id:: 64552bf8-10f4-43e8-a07b-b5a2525d1428 + hl-color:: yellow + - 也有HTM硬件设计的东西（在eADR之前） + - System Transactions and Transactional FS. + ls-type:: annotation + hl-page:: 14 + hl-color:: yellow + id:: 64552acd-0001-4ec1-8fc5-59187f8cfc3d + - 在OS里面用使用 HTM trx + - FS 提供 事务 接口（而HTMFS只是用事务来实现POSIX而已） + - HTM-assisted OCC + ls-type:: annotation + hl-page:: 14 + hl-color:: yellow + id:: 64552b13-6de1-4f6c-9513-8dccdbe11371 + - 在数据库上用HTM来提供并发性能，也有用切片的方法适应长程操作的研究 + - Page fault in RTM. + ls-type:: annotation + hl-page:: 14 + hl-color:: yellow + id:: 64552b5a-d18e-443e-b77c-9b4700aedfea + - 前期的工作解决了该问题，通过修改RTM硬件来识别PF \ No newline at end of file diff --git a/logseq/bak/pages/hls__XPC_Architectural_Support_for_Secure_and_Efficient_Cross_1682647057931_0/2023-05-10T04_11_37.721Z.Desktop.md b/logseq/bak/pages/hls__XPC_Architectural_Support_for_Secure_and_Efficient_Cross_1682647057931_0/2023-05-10T04_11_37.721Z.Desktop.md new file mode 100644 index 0000000..0228eac --- /dev/null +++ b/logseq/bak/pages/hls__XPC_Architectural_Support_for_Secure_and_Efficient_Cross_1682647057931_0/2023-05-10T04_11_37.721Z.Desktop.md @@ -0,0 +1,741 @@ +file:: [XPC_Architectural_Support_for_Secure_and_Efficient_Cross_1682647057931_0.pdf](../assets/XPC_Architectural_Support_for_Secure_and_Efficient_Cross_1682647057931_0.pdf) +file-path:: ../assets/XPC_Architectural_Support_for_Secure_and_Efficient_Cross_1682647057931_0.pdf + +- ABSTRACT + ls-type:: annotation + hl-page:: 1 + hl-color:: yellow + id:: 644b281a-d7fa-4163-8e75-a39d74215bfa + - Motivation: resurgent interest in microkernel, mobile devices + - 微内核需要很多的 IPC 来保持隔离性，但是IPC 操作很慢。 + - seL4 single way fast path - 468 cycles; Fuchsia - over 10k round-trip + - 相对于宏内核而言，性能差很多 + - 宏内核也有 IPC 性能问题 + hl-page:: 1 + ls-type:: annotation + id:: 645656b2-93db-4a0b-913a-1a3887c51e83 + hl-color:: yellow + - Android application & user-level services + - Android Binder 机制： + - 一般而言，IPC （比如管道）要先 copy to kernel buffer 再 copy from kernel buffer + - Binder 的原理是用内存映射，两个进程映射到同一个 kernel buffer 上面，这样 sender 把数据放进去之后，receiver 就能直接用了 + - 两个主要的耗时：1) domain switching, and 2) message copying + hl-page:: 1 + ls-type:: annotation + id:: 645657b7-afa3-47b8-af22-420c1b276d2e + hl-color:: yellow + - 上下文切换有很多指令的overhead + - 共享内存有安全问题，TOCTTOU + - 页表重映射会导致TLB 大量miss + - Previous work + ls-type:: annotation + hl-page:: 2 + hl-color:: yellow + id:: 645658e6-082b-4c9c-90f1-cf172fe91328 + - Software 还是要 trap + - Hardware 用 tagged memory 代替页表来减少 switch 的耗时，但是内核要大改 + - The design has four goals: + ls-type:: annotation + hl-page:: 2 + hl-color:: yellow + id:: 645658a9-a477-47cf-bad2-7a5b4bd91683 + - 不 trap、0拷贝、kernel 小改、hardware 小改 + - new primitive contains three parts + ls-type:: annotation + hl-page:: 2 + hl-color:: yellow + id:: 645658bc-32e3-476b-a1b1-0f3540268e3f + - new hardware-aware abstraction, x-entry + ls-type:: annotation + hl-page:: 2 + hl-color:: yellow + id:: 64565a96-6cd8-467c-a29a-bd6414a4e138 + - xcall-cap, for access control + ls-type:: annotation + hl-page:: 2 + hl-color:: yellow + id:: 64565aab-ff63-4b68-95c9-e3cb9643c9d7 + - 新指令使得IPC不用陷入内核 + hl-page:: 2 + ls-type:: annotation + id:: 64565abb-3c48-4bdd-89ad-7ef0a424bcbc + hl-color:: yellow + - new address-space mapping mechanism, relay-seg, for zero-copying message passing + hl-page:: 2 + ls-type:: annotation + id:: 64565ae6-b80f-4f0b-b738-fc79efc17aeb + hl-color:: yellow + - ownership transfer for TOCTOU, no TLB flush, handover in invoking chain + - synchronous IPC + ls-type:: annotation + hl-page:: 2 + hl-color:: yellow + id:: 64565b4b-aa86-4c99-a02a-9fff0d9d0dd0 + - 解决了低 throughput 和难用的多线程模型 + hl-page:: 2 + ls-type:: annotation + id:: 64565b70-e31c-4e24-8b1f-3511313cc0f4 + hl-color:: yellow + - the migrating thread model + hl-page:: 2 + ls-type:: annotation + id:: 64565b7c-f2d8-49fe-b6a6-8fdc275c1e75 + hl-color:: yellow +- 2 MOTIVATION + ls-type:: annotation + hl-page:: 2 + hl-color:: yellow + id:: 64565a29-7ced-4d34-8580-fe584783a35b + - 2.1 IPC Performance is Still Critical + ls-type:: annotation + hl-page:: 2 + hl-color:: yellow + id:: 64565d37-df65-4458-b1f2-838473637201 + - 测试：YCSB（workload generator for benchmarking KV stores）， seL4，SQLite3 + - IPC 占用了 20-40% 的时间 + - IPC 过程中，大概一半的时间在复制数据，当然对于短IPC，大部分时间在 ctx switch（这个时间基本上是固定的） + - 2.2 Deconstructing IPC + ls-type:: annotation + hl-page:: 3 + hl-color:: yellow + id:: 64565e5f-50d5-4cc6-b9ae-e8451556bb24 + - two paths of IPC in seL4 + hl-page:: 3 + ls-type:: annotation + id:: 64565e70-647b-4f21-aaae-d94476a15c2f + hl-color:: yellow + - Fast Path and Slow Path， slow 相较于 fast 是它允许调度和中断 + - Trap & Restore + hl-page:: 3 + ls-type:: annotation + id:: 64565ed3-701f-4502-bed8-028aefdb26df + hl-color:: yellow + - Caller trap to kernel, kernel restore to callee + - 切换是为了隔离，而隔离是因为假设进程之间的 untrust + - 可以考虑让 IPC 的两边手动管理这个切换的过程以减少开销 + - 类似于什么，拥有不同地址空间的多线程？乐 + - IPC Logic: major task is checking + hl-page:: 3 + ls-type:: annotation + id:: 64565f91-f8a0-4a82-9d9e-74097c36b04f + hl-color:: yellow + - seL4 用 `capability` 管理资源 + - The kernel first fetches the caller's capability and checks its validity + hl-page:: 3 + ls-type:: annotation + id:: 645665f4-2ade-401d-8959-13ad94c0aaa2 + hl-color:: yellow + - 然后决定 slow/fast path + - caller/callee: have different priorities, on different cores + - message size: register-size, buffer-size + - 硬件实现部分的 checking 逻辑。 + - Process Switch + ls-type:: annotation + hl-page:: 3 + hl-color:: yellow + id:: 64565f99-ea28-4791-9a09-92fea39fabd8 + - 切换到 callee， 需要操作调度队列、修改进程状态、传递msg 以及设置 AS + - To make the callee have the capability to reply, a reply_cap is added into the callee thread + ls-type:: annotation + hl-page:: 3 + hl-color:: yellow + id:: 64566730-0b70-4cac-a6d6-97144d9d3462 + - 这个过程中的内存访问可能会导致 cache 和 TLB miss + - Message Transfer + ls-type:: annotation + hl-page:: 3 + hl-color:: yellow + id:: 64565f9d-4bb9-49e9-b070-85e8b71706e0 + - 3 ways according to message length + - 小于 register size ： 在 process switch 的时候复制 + - 小于 IPC buffer size：用 slow path 复制 + - 共享内存 + - 如果直接共享内存，会导致安全和一致性问题。所以一般还是会复制一次，性能垃圾 + - The message transfer dominates the IPC cycles when the message size is large. + ls-type:: annotation + hl-page:: 3 + hl-color:: yellow + id:: 6456684a-d557-4679-8747-044e6dfd7d04 +- 3 DESIGN + ls-type:: annotation + hl-page:: 3 + hl-color:: yellow + id:: 64565fad-b594-408c-b404-4f04469c4fef +- 3.1 Design Overview + ls-type:: annotation + hl-page:: 3 + hl-color:: yellow + id:: 64565fb7-e274-465f-bf50-20dba1c8fde9 + - User-level Cross Process Call + ls-type:: annotation + hl-page:: 3 + hl-color:: yellow + id:: 6456687d-1f7b-4918-942f-78a3c66bdad3 + - 有很多的 `x-entry` 记录可 IPC 的 procedure，然后有一个ID作为它在表里面的 Index + hl-page:: 3 + ls-type:: annotation + id:: 645668e1-ad08-4f89-b860-5fcbd4c57764 + hl-color:: yellow + - 全局的 `x-entry-table` ，配套一个 `x-entry-table-register` 存基地址、和 `x-entry-table-size` 当界限 + - `xcall-cap` 规定了每个 `x-entry` 的 IPC capabilities，这个东西是通过一个 capability bitmap 来做的 + - `xcall #reg` 和 `xret` 指令 + - Lightweight Message Transfer `relay-seg` 机制 + ls-type:: annotation + hl-page:: 4 + hl-color:: yellow + id:: 64566b0b-9fd9-474f-aeea-aa032fbca2d5 + - 一个 `relay-seg` 是一块 ==物理连续== 的内存 + - 内存地址翻译通过新的 reg `seg-reg` 完成，同时`seg-reg`在 caller 和 callee 之间传递，因此 callee 可以直接访问 + - OS 需要保证这块物理地址不会被常规的页表映射占用 + - 因为没有了页表，也就不存在 TLB miss 带来的损失 + - XPC Programming Model + ls-type:: annotation + hl-page:: 4 + hl-color:: yellow + id:: 64566c7e-7f1d-4cdc-86af-6f1705582814 + - Both Capability & Page table + - 代码的例子说是，server 注册 `xpc_register( handler, handler_thread, max_xpc_ctx)`，然后 handler `xpc_return()`， client 先用 `alloc_relay()`构造参数再调用 `xpc_call(server_ID, xpc_arg)`。 + - ~~不是很理解的是，它这里为了支持多个同时调用，给开了个线程？~~ + - 大概指的是后面的 C-Stack 机制，不过这也是纯纯的猜 +- 3.2 XPC Engine + ls-type:: annotation + hl-page:: 4 + hl-color:: yellow + id:: 64565fbe-0166-4201-9078-60168c1045c3 + collapsed:: true + - xcall + ls-type:: annotation + hl-page:: 4 + hl-color:: yellow + id:: 64567422-a004-4862-a497-c7ef75be73aa + - check caller's xcall-cap, reading `xcall-cap-bitmap[#reg]` + - load target `x-entry`, check valid bit + - push `linkage-record` with necessary info for ret, to `link-stack` (per-thread stack) + - load new page table pointer, set PC to `x-entry` 's entrance, with caller's `xcall-cap-reg` copied to some GPR for identification + - xret + ls-type:: annotation + hl-page:: 4 + hl-color:: yellow + id:: 64567428-20ea-4554-ad8f-042aad00449d + - pop a *linkage-record* and return, with assistance of the popped data, and valid-bit checked + - xcall-cap + ls-type:: annotation + hl-page:: 5 + hl-color:: yellow + id:: 645677fd-f9ea-4b7f-9fa3-50a136bc524f + - a per-thread bitmap, each index `i` indicating whether this thread is permitted to call `x-entry[i]` + - with its memory region pointed by `xcall-cap-reg` + - Link Stack + ls-type:: annotation + hl-page:: 5 + hl-color:: yellow + id:: 64567819-b985-4543-80da-acf416609a79 + - a per-thread stack, only accessible by kernel + - not saving GPR + - a principle that `linkage-record` should maintain information which can not be recovered by user-space. + hl-page:: 5 + ls-type:: annotation + id:: 6456796a-9354-48f9-b050-d0c052537225 + hl-color:: yellow + - A lazy write optimization, context-switching while saving record + - XPC Engine Cache + ls-type:: annotation + hl-page:: 5 + hl-color:: yellow + id:: 6456781d-cbb0-4e2e-b396-04edfa67801e + - pre-fetch `x-entry` + - software-managed cache + - hl-page:: 5 + ls-type:: annotation + id:: 64567a42-2b36-4ed5-8505-01f574d5740a + hl-color:: yellow + 1. IPC has high temporal locality (for a single thread); + 2. IPC is predictable. +- 3.3 Relay Segment + ls-type:: annotation + hl-page:: 5 + hl-color:: yellow + id:: 64565fc3-b632-4cb5-949e-3f96d9ce5f2f + - relay-seg + ls-type:: annotation + hl-page:: 5 + hl-color:: yellow + id:: 64567cca-6189-4008-a36e-f04ddfcdbd8c + - add a register `seg-reg` = `VA | PA | Len | Perm` + - prior to TLB, direct-map VA to PA (contiguous physical memory) + - `relay-seg` 指的是一块内存，而 `seg-reg` 表示的是一个映射 + - seg-mask + ls-type:: annotation + hl-page:: 5 + hl-color:: yellow + id:: 64567cc7-b245-4d66-8d32-6c9dec52f0d7 + - 设计者不希望用户程序直接修改 `seg-reg` 的映射，因此加了一个`seg-mask` 用来把当前进程的 `seg-reg` 切出来一部分再传递 + - 主要是用来 invoking chain 的，可能是作者认为这种情况比较常见吧 + - Multiple relay-segs + ls-type:: annotation + hl-page:: 5 + hl-color:: yellow + id:: 64567ccf-8fae-49c0-af3d-6082254bf2dd + - per-process memory region called `seg-list` managed by OS kernel, `seg-list-reg` + hl-page:: 5 + ls-type:: annotation + id:: 6457060d-d314-4136-a9e8-c26babc7888d + hl-color:: yellow + - `swapseg #reg` 指令用来更换当前的 `seg-reg` `#reg` 是目标在 `seg-list` 里面的下标；当然也可以用来 invalidate （指定无效的ID） + - Ownership of relay-seg + ls-type:: annotation + hl-page:: 5 + hl-color:: yellow + id:: 64570676-1f3f-43ef-a16b-77fda80832b8 + - kernel （可能是通过调度器？）保证每个 `relay-seg` 任意时刻只能在一个CPU core 上运行，也就是 owned by one thread + - 反正 paper 里面没写这东西咋实现的 + - 说是能够防止 TOCTOU，大概是防止了别人瞎改 `relay-seg` 的内容吧 + - Return a relay-seg + ls-type:: annotation + hl-page:: 5 + hl-color:: yellow + id:: 64570679-5acf-4701-b718-f1d3b22d3df7 + - 硬件保证 `seg-reg` 在 `xret` 的时候和存在 `linkage-record` 里面的是一致的 + - 奇妙的安全检查机制 + - emmm，它好像没说怎么创建这些东西的接口？ +- 4 IMPLEMENTATION + ls-type:: annotation + hl-page:: 5 + hl-color:: yellow + id:: 6457122f-9508-4e29-828e-55c40dbcbfbc +- 4.1 Integration into RocketChip + ls-type:: annotation + hl-page:: 5 + hl-color:: yellow + id:: 64571250-753f-4f6c-b402-926ef4594c06 + - XPC Engine + ls-type:: annotation + hl-page:: 5 + hl-color:: yellow + id:: 64571300-8f9d-4e88-83c9-5b37f125f5ab + - Implemented as a unit of a RochetChip core + - 新加的寄存器通过 CSR 实现，用`csrr/csrw` 读写 + - **3 new instructions** are sent to the XPC engine in Execution stage. XPC engine checks the validity of an IPC and returns the callee information to the pipeline. + hl-page:: 5 + ls-type:: annotation + id:: 645743fe-eb6b-423d-9d5a-cbc3b7df928c + hl-color:: yellow + - 加了5个 exception + - cache 只有一个 entry 且通过软件进行管理。 prefetch 通过 `xcall` negative ID 的方式实现 + - XPC Management + ls-type:: annotation + hl-page:: 5 + hl-color:: yellow + id:: 645744ef-f6e9-492c-b177-d863c5d6d847 + - 4 XPC objects + - global `x-entry-table`; pet-thread `link stack`; per-thread `x-call-cap` bitmap; per-address-space `relay segment list` + - 在系统启动的时候，kernel 会分配一个1024项的`x-entry-table`；而创建线程的时候，会分配8K的 `link stack` 和128B的`cap-bitmap`以及4K的`seg-list` + - During a context switch, the kernel saves and restores the per-thread objects. + hl-page:: 6 + ls-type:: annotation + id:: 6457467f-aedf-4029-ad71-b82f62aef329 + hl-color:: yellow + - 认真的吗，只是存寄存器吧。。。 + - 不过如果 entry-table 要是扩大的话，是不是cap-bitmap也要跟着扩大。。。 +- 4.2 Support for Microkernels + ls-type:: annotation + hl-page:: 6 + hl-color:: yellow + id:: 64571268-b744-43ab-9e30-12ae6f2451a4 + - Capability + ls-type:: annotation + hl-page:: 6 + hl-color:: yellow + id:: 6457475b-0571-4108-b314-2538d8da6ca9 + - kernel 里面实现一个新的 `grant-cap`，用来管理 thread 是否能向其他 thread grant capability + hl-page:: 6 + ls-type:: annotation + id:: 645748ff-d344-4e9c-960f-c87244307900 + hl-color:: yellow + - kernel 管理每个 thread 的 `grant-cap-list`，所有这个线程注册的 x-entry 都会有一个对应的条目在这个里面，说明当前线程能够把这个 x-entry 的访问权 grant 出去 + - Split Thread State + hl-page:: 6 + ls-type:: annotation + id:: 64574760-c162-414f-a629-7bff2dbeb240 + hl-color:: yellow + - 因为 x-call 切换线程不需要经过内核，因此 kernel 不知道线程已经切换了，当前的线程会被ntr，要是中途来个 page fault 就直接去世了 + - separate the kernel-maintained thread state into two parts: scheduling state and runtime state + ls-type:: annotation + hl-page:: 6 + hl-color:: yellow + id:: 64574e12-9654-4679-855c-b5ad8d6d2341 + - scheduling state: kernel stack, priority, time slice -- sched to other thread + - runtime state: address space, capabilities -- serve this thread + - 每个线程 bind 一个 scheduling state，但是可以有多个 runtime state。kernel 可以通过 per-thread `xcall-cap-reg`来判断 runtime state，因为这玩意在 xcall 的时候会被更新 + - Per-invocation C-Stack + ls-type:: annotation + hl-page:: 6 + hl-color:: yellow + id:: 64574769-7ecc-49a5-9a7f-33de410ed641 + - 支持一个 `x-entry` 同时被调用 + - library 提供 per-invoke XPC context，包括 execution stack (C-stack) 和 local data + - 注册 x-entry 的时候会提前创建这些 context + - 在调用的时候用一个 trampoline 来选择可用的context、切换C-stack、保存local data，以及返回的时候重载数据 + - 作者提到了 DoS 攻击的可能性，什么恶意进程疯狂调用来占满所有的context。 + - XPC allows each server to adopt specific policies to limit the invocation from clients + ls-type:: annotation + hl-page:: 6 + hl-color:: yellow + id:: 64575485-dcce-4bb6-bc9a-1f89f5f33a9d + - ((645796d4-5e4b-41ea-be08-6545fc8c26a6)) + - Application Termination + ls-type:: annotation + hl-page:: 6 + hl-color:: yellow + id:: 6457476d-bc89-4bab-8b7e-b00e332a8c60 + - 考虑 invoking chain A->B->C 上中间进程B突然挂掉了，后续的进程C可能会返回到已经终止的进程 + - 在一个进程B终止的时候，kernel 检查所有的`linkage stack` 然后 invalidate 所有属于这个进程B的 entry。这样后续进程C返回的时候，就会触发 `linkage invalid exception`，由 kernel 负责 pop 这个 linkage record 并返回到更先前的进程A + - ？进程的回收也是个问题，难不成等所有的 linkage 全 pop 完了才回收吗 + - 扫描所有的 linkage 效率太低，一个优化：可以在 B 终止的时候清空B的页表而不扫描所有的 linkage stack，这样返回的时候就会有 page fault 陷入 kernel 了 +- 4.3 Support for Android Binder + ls-type:: annotation + hl-page:: 7 + hl-color:: yellow + id:: 64571271-ee10-47f9-8c6e-97a7211b7c94 + - 修改了下层的 Binder driver 和中间框架，上层API保持兼容 + - Binder transaction + ls-type:: annotation + hl-page:: 7 + hl-color:: yellow + id:: 645760b0-3819-4dbc-af65-e5edef87061b + - client 有一个 method code 用来指定 remote method + - client Binder object 调用 `transcat()` 进入 Binder driver，把 userspace buffer 复制到 kernel buffer，然后切到 server 在把 kernel buffer 复制到 server 的 userspace buffer。 + - 2 copies，2 switches + - server Binder object 收到后执行 handler `onTransact()` + - 最后通过 driver reply 回去 + - XPC 实现 + ls-type:: annotation + hl-page:: 7 + hl-color:: yellow + id:: 64576c77-d72b-4ade-b85a-2d8e94ba606e + - 用 Binder driver 管理 xcall-cap 和 x-entry table + - server 通过 Binder 注册的时候，framework 会 ioctl Binder driver 来新建 x-entry + - client 请求服务的时候，framework 需要 ioctl Binder driver 来设置 xcall-cap + - client 调用的时候，framework 直接用 xcall 指令并用 relay-reg 来传递 marshalled data + - Linux Kernel 需要作修改来解决前述的线程管理问题 ((64574760-c162-414f-a629-7bff2dbeb240)) + - Ashmem: Anonymous Shared Memory + hl-page:: 7 + ls-type:: annotation + id:: 64576a2a-af0d-40e5-8f4b-3cc5010056bb + hl-color:: yellow + - file-based interface，可以通过文件描述符和其他进程共享内存 + - In Android Binder, processes can share fd of an ashmem through Binder driver. + hl-page:: 7 + ls-type:: annotation + id:: 64576ae1-5b66-4d2a-9915-60e3505ef738 + hl-color:: yellow + - XPC 实现 ashmem + - 分配：用 Binder driver 分配一个 relay-seg + - map: allocate VA and set `seg-reg` + - transfer: passing `seg-reg` in the framework during `xcall` + - 存在问题：因为前述的实现中，只有一个 `seg-reg`，因此如果想要同时用多块 ashmem，就只能通过 page fault 或者 `swapreg` 指令来切换 `seg-reg` 来实现 + - 加个cache？感觉会变成新的TLB了 + - 好处是不需要拷贝两次了 +- 4.4 Handover along Calling Chain + ls-type:: annotation + hl-page:: 7 + hl-color:: yellow + id:: 64571276-8880-47f4-addd-b03d3057b7bf + - Message Size Negotiation + ls-type:: annotation + hl-page:: 7 + hl-color:: yellow + id:: 64576204-098c-4a39-8ba5-9c6811c8b5d7 + - 为了避免在后续调用中空间不够用，可以在一开始申请 relay-reg 的时候就预留一部分空间 + - 这就需要 invoking chain 上的所有进程协商一个大小 + - 不过感觉实现起来也，不是很高效的样子（除非大小是固定的，就跟RTOS一样），就看怎么设计权衡了 + - Message Shrink + ls-type:: annotation + hl-page:: 7 + hl-color:: yellow + id:: 645763ab-7182-4d43-abc6-2e351ecfd599 + - 用 seg-mask 实现只传递一部分的 message 给 next level on the chain + - Segment Revocation + ls-type:: annotation + hl-page:: 8 + hl-color:: yellow + id:: 645763f1-9fe6-4c34-9392-e03a8b70ddb9 + - 进程终止的时候 kernel 扫描它的 seg-list 然后把有 caller 的 relay-reg 还回去，如果是自己申请的就回收 +- 5 EVALUATION + ls-type:: annotation + hl-page:: 8 + hl-color:: yellow + id:: 6457127a-7663-4375-9e93-f43ed6c06976 + - 5.2 Microbenchmark + hl-page:: 8 + ls-type:: annotation + id:: 64576ea8-1038-44f5-a703-78a40e714b38 + hl-color:: yellow + - Config + - Full-Ctx (save/restore full context), Partial-Ctx + - +Tagged TLB, +NonBlock Link Stack, +XPC Engine Cache + - 在一次调用中，主要有3部分开销 + - 如果没开 TLB 优化，TLB miss 会占一部分 + - trampoline, 保存上下文的时间 + - xcall logic，主要包括 Linkage stack 和取 seg-reg 的时间，可以通过 nonblock 和 xpc cache 优化 + - In the following evaluation, XPC will use “Full-Cxt” with “Nonblocking Link Stack” optimizations, to ensure the fairness of the comparison. + ls-type:: annotation + hl-page:: 8 + hl-color:: blue + id:: 6457741f-f4e3-47d4-894c-f70936ceb646 + - One-way Call 这里统计应该是从 client 调用 request 开始到 server 收到 onRequest + hl-page:: 8 + ls-type:: annotation + id:: 64577417-b2ff-4ba9-93ca-9b1a2e2cad5b + hl-color:: yellow + - 由于 XPC 不需要拷贝，所以开销很低 + - 如果是普通的 seL4，耗时会随着消息长度而增长。 + - 从它的图上看，slow path (32-120Byte) 的耗时甚至比 shared memory(128Byte) 要长 + - Multi-core IPC + ls-type:: annotation + hl-page:: 8 + hl-color:: yellow + id:: 6457750c-0dc6-4bb8-b7a5-d6e7bf0c8846 + - 这个cross core和same core完全一样，对照组延时就直接起飞了，好怪啊。他说是因为它的 migrating thread model 和它的优秀的locality + - 不过，TLB你说是因为你用 seg-reg 给替代了倒也合理，cache 换核心了必然要寄掉的啊（难道是L2？） + - 好像也，能理解？毕竟ICache/ITLB miss无论单核多核都是必要的，DCache/DTLB 因为不拷贝所以两种都不miss，然后那些个检查本来都是要miss一遍的。seL4因为跨核心了，所以必然是用slow path，外加因为跨核心导致的各种miss + - Moreover, a client can easily scale itself by creating several worker threads on different cores and pull the server to run on these cores. + ls-type:: annotation + hl-page:: 9 + hl-color:: yellow + id:: 6457788c-f190-455c-ab53-4c3fc77899ba + - Other Instructions + ls-type:: annotation + hl-page:: 9 + hl-color:: yellow + id:: 6457776f-ef59-41ff-b236-d2a010eb8250 + - 就，测了测 `xcall/xret/swapreg` 这些指令的周期，主要是访存的时延 + - 5.3 OS Services + ls-type:: annotation + hl-page:: 9 + hl-color:: yellow + id:: 64576ff6-bfd7-4dfa-952b-fcb3b1e82d1f + - File System + ls-type:: annotation + hl-page:: 9 + hl-color:: yellow + id:: 64577b2d-646d-4b0b-a5b0-ccc79d9e24e2 + - In microkernels, a file system usually includes two servers, a file system server and a block device server + ls-type:: annotation + hl-page:: 9 + hl-color:: blue + id:: 64577dca-1183-4b1c-ba74-a107ff1d3f56 + hl-stamp:: 1683455439580 + - 测试用了一个 Log-structured FS 和一个 ramdisk device + - 对于写操作效果比较好，因为涉及到许多要拷贝很多数据的IPC + - Network + ls-type:: annotation + hl-page:: 9 + hl-color:: yellow + id:: 64577b31-ad0a-4dd2-969c-03e960791649 + - Microkernel systems usually have two servers for network: one network stack server (including all network protocols) and one network device server. + ls-type:: annotation + hl-page:: 9 + hl-color:: blue + id:: 64577e7c-2b07-4986-acc6-bb7248cf9aad + - 测试移植了一个协议栈和一个 loopback driver device + - 到后面数据量大了，加速效果会降低，因为IPC的数量被摊平了（data get batched） + - 5.4 Applications + ls-type:: annotation + hl-page:: 9 + hl-color:: yellow + id:: 64577000-b38c-449a-ab4b-038569490568 + - SQLite3: YCSB-A and YCSB-F gain the most improvement because they have ==a lot of write/update== operations which will trigger ==frequent file access==. YSCB-C has minimal improvement since it is a ==read-only workload== and Sqlite3 has an ==in-memory cache== that can handle the read request well. + hl-page:: 9 + ls-type:: annotation + id:: 64577f97-4e63-431b-bd09-1d6eea865836 + hl-color:: yellow + - Web Server: Most of the benefit comes from ==handover optimization==. Since in multi-server cases, the message will be transferred multiple times. + hl-page:: 9 + ls-type:: annotation + id:: 64577ffb-c30d-411c-bdf0-cc172f291786 + hl-color:: yellow + - 5.5 Android Binder + ls-type:: annotation + hl-page:: 9 + hl-color:: yellow + id:: 64577010-66d9-43ef-b304-846fb028414a + - 测试了在 WM 和 Compositor 之间的 IPC，两种方法 buffer 和 ashmem + - buffer 大小受限，因此只测了小数据；ashmem在小数据的情况下和buffer差不多 + - ashmem在大数据的情况下的优化倍率就比较小了 + - 同时测试了只用 relay-seg 而不用 xcall 的实现，在小数据的情况下自然是不如全套实现，大数据下差不多，因为这时候的优化主要都来自于zero-copy + - 5.6 Generality + ls-type:: annotation + hl-page:: 10 + hl-color:: yellow + id:: 64577019-21ad-4ff1-b8a5-77f0be884b2c + - 用了一个周期精确的模拟器来模拟一个 in-order ARMv8-A + - use microOps to implement the functionalities of XPC engine + ls-type:: annotation + hl-page:: 10 + hl-color:: yellow + id:: 64578330-b7bb-418d-b9a4-5b7e997f6b45 + - 没有 cache 和 nonblocking 优化 + - 因为seL4没有支持，甚至还搞了个 instruction trace 出来。。。 + - 然后这模拟器还没有 TLB flush cost，甚至还专门用个什么 barrier 来模拟它 + - 提升自然是有的，只不过比较抽象 + - 5.7 Hardware Costs + ls-type:: annotation + hl-page:: 11 + hl-color:: yellow + id:: 64577026-3083-4275-99e1-afa698407303 + - 其实还行，也就多用了三四百个FF和LUT。不过我觉得就算用 verilog 重写一遍也不见得能优化多少 +- 6 DISCUSSION + ls-type:: annotation + hl-page:: 11 + hl-color:: yellow + id:: 6457128a-0799-4b0f-aef7-1dca6ef6fdec + - 6.1 Security Analysis + ls-type:: annotation + hl-page:: 11 + hl-color:: yellow + id:: 645783e4-939f-44c2-ad4f-ba6547483686 + - XPC Authentication and Identification + ls-type:: annotation + hl-page:: 11 + hl-color:: yellow + id:: 64579586-3e38-494b-9d6c-a070c776bc22 + - xcall 指令有 xcall-cap 检查, 需要从具有对应的 grant-cap 的 server 那里请求, 类似于 nameserver + - server 可以通过 `xcall-cap-reg` 来获知调用者, 也是一种鉴权方法 + - Defending TOCTTOU Attacks + ls-type:: annotation + hl-page:: 11 + hl-color:: yellow + id:: 6457958b-9c34-4b6e-9728-779866f4dd6f + - 保证 relay-seg 同一时间只能由一个 thread 持有 ((64570676-1f3f-43ef-a16b-77fda80832b8)) + - kernel 保证 relay-seg 映射的地址和其他地址不重叠, 因此也不会被瞎改 + - Fault Isolation + ls-type:: annotation + hl-page:: 11 + hl-color:: yellow + id:: 645796cd-b37a-4f2b-a19c-9b48c0614a91 + - 由于 ((6457476d-bc89-4bab-8b7e-b00e332a8c60)) 和 ((645763f1-9fe6-4c34-9392-e03a8b70ddb9)), caller 和 callee 不会相互影响 + - XPC 提供了 timeout 机制防止 callee 把 caller 给 hang 掉 + - Defending DoS Attacks + ls-type:: annotation + hl-page:: 11 + hl-color:: yellow + id:: 645796d4-5e4b-41ea-be08-6545fc8c26a6 + - create a lot of relay-seg which requires many continuous physical memory, which may trigger external fragmentation + hl-page:: 11 + ls-type:: annotation + id:: 64579853-231a-4d42-aea1-c5679a27126c + hl-color:: yellow + - XPC通过将 `relay-seg`塞进进程的私有地址来解决这个问题, 至少不会让整个 OS 炸掉 + - 至于耗光 context 的问题, XPC 用 credit system 来解决, 也就是检查 caller 是否有足够的 credits + - Timing Attacks + ls-type:: annotation + hl-page:: 11 + hl-color:: yellow + id:: 645796da-4e3d-4dfb-b772-a0dcf97f6698 + - 为啥? 类似于 meltdown 那种吗, 没想明白 + - 6.2 Further Optimizations + ls-type:: annotation + hl-page:: 11 + hl-color:: yellow + id:: 645783e8-7a78-4fd5-8d3a-9edd46cd164d + - Scalable xcall-cap + ls-type:: annotation + hl-page:: 11 + hl-color:: yellow + id:: 64579af6-4b18-4be9-ad30-752d2e45e0b1 + - 因为bitmap大小是固定的 + - 可以考虑用 radix-tree, 但是访存延时会增加 + - Relay Page Table + ls-type:: annotation + hl-page:: 11 + hl-color:: yellow + id:: 64579b27-3285-445e-afb7-0ffb806f686d + - 现在的 relay-seg 必须物理连续 + - 可以用不同的页表来实现这个事情 + - 但是 granularity 会变大, 而且ownership转移会有问题??? + - 猜测是涉及到页表的加载切换 +- 7 RELATED WORK + ls-type:: annotation + hl-page:: 11 + hl-color:: yellow + id:: 6457128f-abd3-476a-8103-2bd4ac1a8dab + - 7.1 Optimizations on Domain Switch + ls-type:: annotation + hl-page:: 11 + hl-color:: yellow + id:: 645784ba-bf63-40e7-adca-1215a1f22ac7 + - Software + - use caller's thread to run callee's code in callee's address space + hl-page:: 11 + ls-type:: annotation + id:: 64579dee-7496-4b47-8efa-cab30ba4ceb8 + hl-color:: yellow + - PPC(protected procedure call) and migrating thread + - L4的direct process switch可以减少切换代价并降低调度频率 + - Hardware + - domain的概念不再是process或者是AS,而是用不同ID标识/隔离的执行单元. + - domain switch的时候不再需要trap,而是可以直接切ID就行了 + - 虽然我也不知道这时候怎么搞隔离 + - 多个domain可以共享地址空间,还能再省一笔 + - 但是这种方法会导致软件需要大改,可移植性很差 + - 也有 hybrid 方法, 或者用硬件虚拟化来做 + - 7.2 Optimizations on Message Passing + ls-type:: annotation + hl-page:: 12 + hl-color:: yellow + id:: 645784c3-7513-49a5-b7da-12e5d1e14455 + - 软件 + - 老老实实复制两遍 + - 地址空间重映射,L4把待传递的消息的地址重映射到只有kernel能访问的地址上,这样就省下来一次拷贝到kernel的过程 + - 不过remapping也还是有不小的overhead + - 硬件 + - a hybrid memory granting mechanism combined with permission list and capability registers. Pass capability register pass memory region + hl-page:: 13 + ls-type:: annotation + id:: 6457a7cb-c723-4243-99ef-be1475d258d2 + hl-color:: yellow + - 感觉和本文差不多? 虽说没有针对TOCTOU做防御,但是本片也不过是kernel保证一下唯一性罢了 + - uses hardware capability pointers (which describe the lower and upper bounds of a memory range) + hl-page:: 13 + ls-type:: annotation + id:: 6457a852-cf47-4a31-924e-e7f8be729b61 + hl-color:: yellow + - 问题在于他是single address space with tagged memory + - use new hardware PLB (protection look-aside buffer) to decouple the permission from the address space translation + ls-type:: annotation + hl-page:: 13 + hl-color:: yellow + id:: 6457a77f-0f05-4e78-b41b-b7cf0ba8fc9d + - 看上去是个可以做remapping的硬件 + - 用DTU,一种类似于DMA的东西,但是对于小数据而言overhead太大 + - 用什么 queue-based hardware accelerators to optimize cross-core communication + hl-page:: 13 + ls-type:: annotation + id:: 6457a742-4c8d-4393-81ad-1648a830bc24 + hl-color:: yellow + - 7.3 Other Related Work + ls-type:: annotation + hl-page:: 13 + hl-color:: yellow + id:: 645784c7-9b11-43e1-9c64-80ba30ebdacb + - Architectural Support for OS Performance + ls-type:: annotation + hl-page:: 13 + hl-color:: yellow + id:: 6457a4d4-08ea-4d2d-ac6d-050a8fc5302b + - Shared Memory for IPC + ls-type:: annotation + hl-page:: 13 + hl-color:: yellow + id:: 6457a4d8-2fec-4600-b1ae-0bcadc3a3237 + - Asynchronous IPC + ls-type:: annotation + hl-page:: 13 + hl-color:: yellow + id:: 6457a4da-cf42-47db-bf8a-e37415d6750f + - Global Address Space Systems + ls-type:: annotation + hl-page:: 13 + hl-color:: yellow + id:: 6457a4e2-c501-4f4e-94ef-6fd1783856f4 \ No newline at end of file diff --git a/pages/hls__HTMFS_Strong_Consistency_Comes_for_Free_with_1682647018871_0.md b/pages/hls__HTMFS_Strong_Consistency_Comes_for_Free_with_1682647018871_0.md index a21f246..6388fdd 100644 --- a/pages/hls__HTMFS_Strong_Consistency_Comes_for_Free_with_1682647018871_0.md +++ b/pages/hls__HTMFS_Strong_Consistency_Comes_for_Free_with_1682647018871_0.md @@ -1,6 +1,20 @@ file:: [HTMFS_Strong_Consistency_Comes_for_Free_with_1682647018871_0.pdf](../assets/HTMFS_Strong_Consistency_Comes_for_Free_with_1682647018871_0.pdf) file-path:: ../assets/HTMFS_Strong_Consistency_Comes_for_Free_with_1682647018871_0.pdf +- 总结 + - 硬件条件：PM可以像DRAM一样读写、eADR可以保证RTM提交后的持久化 + - 动机：现有的基于PM的FS依然在用老旧的一致性方法，复杂而低效；HTM是个好东西，但是有容量、指令类型、冲突等限制 + - 设计思路： + - HOP：把FS操作拆解成小块，关键数据写入塞进RTM里面；大块的数据写入用 shadow page + 指针更新实现；读取用 sequence number 和RTM内验证来保证一致性。 + - HTMFS： + - 文件：文件组织还是INODE+指针，只不过块指针附上了seqno；写入的时候先写shadow page，然后在RTM内更新元数据；块分配主要解决leak问题，通过一个临时freelist记录分配但未提交的块，块回收采用类似的方法。 + - 目录：目录组织用的是INODE->Hash-table->Entry-Block这样的结构，hash-bucket和entry-item上分别附加了bseq和dseq。读取目录的时候，记录每一级的dseq并验证；修改目录的时候，插入用bseq验证，其他的好像用dseq，全部在RTM里面执行写入。 + - 实现过程：基于 ZoFS 来做，分为KernFS和LibFS两个部分。KernFS主要就是个分配管理器，把页面外包给LibFS；LibFS具体实现HTMFS，并通过KernFS请求和返还空间。还有 Fallback path 和 abort prevention 策略 + - 性能： + - memcpy指令导致的性能问题、分配清空memset导致的问题、PM的带宽限制导致并发数增加到一定程度之后就不再scale + - lock-free、hash-bucket、以及fine-grained 并发控制使得HTMFS性能和scalability不错 + - 正常情况下 abort 不是很多，高abort-rate下fallback path 的性能也还不错 + - 对比了保证一致性带来的代价，性能下降不明显 - Abstract ls-type:: annotation hl-page:: 2 @@ -11,7 +25,8 @@ file-path:: ../assets/HTMFS_Strong_Consistency_Comes_for_Free_with_1682647018871 hl-page:: 2 hl-color:: yellow id:: 644b2866-2f98-49f4-a914-2d1400d47e3b - - Earlier FSs optimize for performance, but provide loose consistency guarantees + collapsed:: true + - 早期的FS主要优化性能，但是没啥一致性保证 - With the speedup of modern storage devices, strong consistency can ease the pain of software programming. - Strong consistency implies per-request sequential consistency. - atomic modification: inode level locks @@ -63,6 +78,7 @@ file-path:: ../assets/HTMFS_Strong_Consistency_Comes_for_Free_with_1682647018871 hl-page:: 3 hl-color:: yellow id:: 6451215b-a495-4d6f-9427-f5c0c6685a28 + collapsed:: true - Persistent Memory and PM File Systems ls-type:: annotation hl-page:: 4 @@ -123,7 +139,7 @@ file-path:: ../assets/HTMFS_Strong_Consistency_Comes_for_Free_with_1682647018871 id:: 645277dc-272c-4479-9d09-3f178cb77a42 - 非常自然的想法：把一个操作，或者说trx，拆成小的 - 三种操作分类： - - Read、Invisible write(内部的东西，比如块分配信息) 、Visible write(应用程序可见的) + - Read、Invisible write(内部的东西，比如块分配信息) 、Visible write(应用程序可见的，文件大小、修改日期之类的) - 只有 Visible Write 用 HTM 实现，Invisible 和 Read 通过别的机制来实现 - （对于一整个FS操作）首先在 RTM 外面完成所需的 read 和 invisible，然后用 RTM 完成 visible，保证它们是 atomic 的。 hl-page:: 5 @@ -184,7 +200,8 @@ file-path:: ../assets/HTMFS_Strong_Consistency_Comes_for_Free_with_1682647018871 ls-type:: annotation id:: 64535ce3-9927-4e22-b2ed-9c396c3b43f2 hl-color:: red - - 不过看上去，它们这边是认为分配一个块是个双向的过程，不仅会在总的freelist里面有记录，block 里面也有一个记录表明它的分配情况？ + - 猜测1：它们认为分配一个块是个双向的过程，不仅会在总的freelist里面有记录，block 里面也有一个记录表明它的分配情况？ + - 猜测2：alloc信息会先写到PM里面，从下面的Allocation一节好像也是基于这个假设，但是这和它前面说的 allocation 在DRAM里面的描述又冲突了 - 3.2.3 Allocation ls-type:: annotation hl-page:: 7 @@ -260,6 +277,7 @@ file-path:: ../assets/HTMFS_Strong_Consistency_Comes_for_Free_with_1682647018871 hl-page:: 9 hl-color:: yellow id:: 64534d45-e498-427d-b4ef-74eaf56f7aae + collapsed:: true - 基于 ZoFS 实现，不过我也不知道它是个啥。它分成两部分，内核里面一部分，还有用户空间的 Library。 - 坏家伙，ZoFS 是也是这帮人自己写的 - 根据权限不同，把整个 FS tree 分成不同的 zone @@ -280,6 +298,7 @@ file-path:: ../assets/HTMFS_Strong_Consistency_Comes_for_Free_with_1682647018871 hl-page:: 9 hl-color:: yellow id:: 6453982f-f915-40ae-a87b-f94a89af4369 + collapsed:: true - 维护每个 zone 内部的 data metadata，比如文件、目录 - 前面的 Design 都是在这里实现的 - KernFS 用 free list 管理分配，如果某个 zone 打 syscall 请求空间， KernFS 返回一个 free list 。为了不修改 kernel side， LibFS 要转换这个 list 使得能够被 HTMFS 识别 @@ -295,6 +314,7 @@ file-path:: ../assets/HTMFS_Strong_Consistency_Comes_for_Free_with_1682647018871 hl-page:: 9 hl-color:: yellow id:: 64539833-3b3c-451b-b550-6d33dd8ac106 + collapsed:: true - 主要原因是 page fault ，但是没法搞，所以事先 access 一下，然后再进 RTM，这样就不太容易在 RTM 里面炸了 - 偶然的 abort，直接 retry ；如果次数太多，那么就 fallback - fallback 策略：先上锁，把 conflict abort 的可能性消除，然后再执行 HOP （或者说是RTM，就是前面的机制，这里只是不让他们冲突了）来保证崩溃一致性 @@ -304,6 +324,7 @@ file-path:: ../assets/HTMFS_Strong_Consistency_Comes_for_Free_with_1682647018871 hl-page:: 10 hl-color:: yellow id:: 64551435-bee3-456a-93f1-8fce14cd5771 + collapsed:: true - Performance comparison with weak consistency FS - Application performance - How HTM improve FS @@ -380,6 +401,7 @@ file-path:: ../assets/HTMFS_Strong_Consistency_Comes_for_Free_with_1682647018871 hl-page:: 12 hl-color:: yellow id:: 6455164b-8ba7-4bef-b5d8-bb59aca3db00 + collapsed:: true - 论文里面写了一个例子。给一个 4KB 的 全a文件写8KB的b字符。 - 先分配一个4K空页 - fill 0-4l diff --git a/pages/hls__XPC_Architectural_Support_for_Secure_and_Efficient_Cross_1682647057931_0.md b/pages/hls__XPC_Architectural_Support_for_Secure_and_Efficient_Cross_1682647057931_0.md index 0228eac..36a3985 100644 --- a/pages/hls__XPC_Architectural_Support_for_Secure_and_Efficient_Cross_1682647057931_0.md +++ b/pages/hls__XPC_Architectural_Support_for_Secure_and_Efficient_Cross_1682647057931_0.md @@ -1,13 +1,80 @@ file:: [XPC_Architectural_Support_for_Secure_and_Efficient_Cross_1682647057931_0.pdf](../assets/XPC_Architectural_Support_for_Secure_and_Efficient_Cross_1682647057931_0.pdf) file-path:: ../assets/XPC_Architectural_Support_for_Secure_and_Efficient_Cross_1682647057931_0.pdf +- 总结 + - 问题：IPC很慢，而微内核需要用到大量的IPC来完成系统功能 + - 相关工作：软件优化还是避免不了trap开销、或者是有一些并发问题；硬件优化需要大规模修改软件。 + - 场景：微内核Zircon和seL4、Android Binder + - IPC分析：两个主要的开销，domain switch 和 message copy + - 在seL4中的一次IPC有几个主要的步骤：Trap-Restore、IPC logic、Process switch、Message transfer + - Trap Restore：caller陷入内核然后加载callee执行 + - IPC logic：检查权限并选择消息传递策略（fast/slow path + - Process switch：线程调度、完成消息传递、权限设置 + - Message transfer：三种方法，reg、buffer、共享内存 + - 硬件设计： + - 除了`seg-mask`之外,其余所有的寄存器和相关的内存均为user只读,kernel结合硬件来维护这些东西 + - x-entry + - 每个x-entry对应一个IPC server过程,记录页表\Cap bitmap地址\入口地址\Seg list地址\valid + - 存放在一个全局的x-entry-table里面，由内核在启动的时候分配。相关的寄存器为`x-entry-table-reg` 和`x-entry-table-size` + - x-cap + - 硬件实现的capability机制,用于检查一个线程是否可以调用某个IPC过程 + - 存放在per-thread的XCALL-cap-bitmap里面 + - linkage + - 记录调用信息,返回的时候要用,所有caller的XPC寄存器都保存在这里,存放在per-thread的linkage stack里面,由`link-reg`指定当前线程的stack + - relay-seg + - 对应连续的物理内存,用于传递消息. 一个进程可以有多个这玩意,对应的映射信息存放在per-address-space的seg-list里面 + - `seg-reg`对应seg-list中的一个entry,具有比TLB更高的优先级,进行地址翻译 + - 该寄存器将在调用时被保持 + - `seg-mask`用来在IPC的时候控制暴露给callee的message的范围 + - 所有权:内核保证每个relay-seg同一时间只能在一个CPU核心上被使用,也就是两个core上的seg-reg不能一样 + - 返回检查:在返回的时候要求seg-reg和进入的时候一致 + - XPC Engine Cache + - 软件管理的cache,可以通过预取来优化xcall + - 指令 + - `xcall #reg` 检查cap,加载并检查目标x-entry,压栈linkage record,切换地址空间并跳转,同时将caller的x-cap-reg存进某一个GPR供callee检查 + - `xret` 出栈linkage recrd,返回caller + - `swapreg #reg` 把seg-reg换成seg-list中对应index的东西(或者invalidate它) + - 软件移植 + - 软件接口 + - `xpc_register( handler, handler_thread, max_xpc_ctx)` + - `xpc_return()` + - `alloc_relay()` + - `xpc_call(server_ID, xpc_arg)` + - `grant-cap`: server将访问某个IPC过程的cap赋予给client,因为cap-bitmap只能内核动,所以要打系统调用,然后内核根据server是否有grant-cap来决定它是否有权grant + - Split Thread State, scheduling state & runtime state(地址空间和Capabilities), 用 x-cap-reg 来作为线程标识, 需要让内核知道现在是在caller还是在callee + - Per-invocation C-Stack, 支持server过程被并发访问,中间加一段代码来选择context.可能会被ddos攻击,需要credit policy控制访问 + - Application termination: 调用链上的进程在返回之前炸了,需要扫所有进程的link stack然后把炸掉进程的record全部invalidate,这样就会触发异常让kernel处理 + - Message size negotiation: 预留一些空间给调用链后面的进程用 + - Message shrink: `seg-mask` + - Segment Revocation: 进程终止的时候,扫描该进程的seg-list,把属于caller的还回去以及回收工作 + - 用XPC实现Android Binder和ashmem + - 修改 Binder Driver 和 Binder framework + - server注册: ioctl driver 增加xentry + - client请求: ioctl driver 赋予xcap + - client调用: xcall,用relay-seg实现数据传递 + - ashmem的allocation(分一个relayseg), map(把VA写进seg-entry), transfer(xcall并传递seg-reg) + - 性能 + - microbenchmark 测试周期数上的优化 + - 三个部分, trampoline,xcall,TLB + - 优化条件: ASID, non-block link stack, xpc cache + - same core 和 cross core + - OS services 测了 FS 和 Network + - 写操作优化比较明显,当然如果软件上有什么减少ipc的buffer那另说 + - Application 测了 YCSB+Sqlite 和 一个服务器 + - FS操作多的优化明显,软件内部有cache的就少一些 + - Android Binder 测了buffer和Ashmem两种方法 + - 由于没改linux内核,只能用machine mode来前述的问题,外加没有asyncIPC + - 测试了binder buffer(但是大小受限)和仅用ashmem两种情况 + - Generality 在一个arm模拟器上又测了测 - ABSTRACT ls-type:: annotation hl-page:: 1 hl-color:: yellow id:: 644b281a-d7fa-4163-8e75-a39d74215bfa + collapsed:: true - Motivation: resurgent interest in microkernel, mobile devices - 微内核需要很多的 IPC 来保持隔离性，但是IPC 操作很慢。 + collapsed:: true - seL4 single way fast path - 468 cycles; Fuchsia - over 10k round-trip - 相对于宏内核而言，性能差很多 - 宏内核也有 IPC 性能问题 @@ -15,6 +82,7 @@ file-path:: ../assets/XPC_Architectural_Support_for_Secure_and_Efficient_Cross_1 ls-type:: annotation id:: 645656b2-93db-4a0b-913a-1a3887c51e83 hl-color:: yellow + collapsed:: true - Android application & user-level services - Android Binder 机制： - 一般而言，IPC （比如管道）要先 copy to kernel buffer 再 copy from kernel buffer @@ -24,6 +92,7 @@ file-path:: ../assets/XPC_Architectural_Support_for_Secure_and_Efficient_Cross_1 ls-type:: annotation id:: 645657b7-afa3-47b8-af22-420c1b276d2e hl-color:: yellow + collapsed:: true - 上下文切换有很多指令的overhead - 共享内存有安全问题，TOCTTOU - 页表重映射会导致TLB 大量miss @@ -32,6 +101,7 @@ file-path:: ../assets/XPC_Architectural_Support_for_Secure_and_Efficient_Cross_1 hl-page:: 2 hl-color:: yellow id:: 645658e6-082b-4c9c-90f1-cf172fe91328 + collapsed:: true - Software 还是要 trap - Hardware 用 tagged memory 代替页表来减少 switch 的耗时，但是内核要大改 - The design has four goals: @@ -39,12 +109,14 @@ file-path:: ../assets/XPC_Architectural_Support_for_Secure_and_Efficient_Cross_1 hl-page:: 2 hl-color:: yellow id:: 645658a9-a477-47cf-bad2-7a5b4bd91683 + collapsed:: true - 不 trap、0拷贝、kernel 小改、hardware 小改 - new primitive contains three parts ls-type:: annotation hl-page:: 2 hl-color:: yellow id:: 645658bc-32e3-476b-a1b1-0f3540268e3f + collapsed:: true - new hardware-aware abstraction, x-entry ls-type:: annotation hl-page:: 2 @@ -65,12 +137,13 @@ file-path:: ../assets/XPC_Architectural_Support_for_Secure_and_Efficient_Cross_1 ls-type:: annotation id:: 64565ae6-b80f-4f0b-b738-fc79efc17aeb hl-color:: yellow - - ownership transfer for TOCTOU, no TLB flush, handover in invoking chain + - ownership transfer against TOCTOU, no TLB flush, handover in invoking chain - synchronous IPC ls-type:: annotation hl-page:: 2 hl-color:: yellow id:: 64565b4b-aa86-4c99-a02a-9fff0d9d0dd0 + collapsed:: true - 解决了低 throughput 和难用的多线程模型 hl-page:: 2 ls-type:: annotation @@ -81,16 +154,20 @@ file-path:: ../assets/XPC_Architectural_Support_for_Secure_and_Efficient_Cross_1 ls-type:: annotation id:: 64565b7c-f2d8-49fe-b6a6-8fdc275c1e75 hl-color:: yellow + - 大概看了原论文，基本的理念和这里的XPC差不多，意思应该是让RPC对内核可见，然后RPC的时候内核不会把client给block掉，而是让client线程执行server的代码，只需要切换一部分寄存器和一部分的地址空间。（作者说类似于 syscall，也有点道理） + - 感觉这篇也就是给这个什么 migrating model 加了硬件支持 - 2 MOTIVATION ls-type:: annotation hl-page:: 2 hl-color:: yellow id:: 64565a29-7ced-4d34-8580-fe584783a35b + collapsed:: true - 2.1 IPC Performance is Still Critical ls-type:: annotation hl-page:: 2 hl-color:: yellow id:: 64565d37-df65-4458-b1f2-838473637201 + collapsed:: true - 测试：YCSB（workload generator for benchmarking KV stores）， seL4，SQLite3 - IPC 占用了 20-40% 的时间 - IPC 过程中，大概一半的时间在复制数据，当然对于短IPC，大部分时间在 ctx switch（这个时间基本上是固定的） @@ -171,6 +248,7 @@ file-path:: ../assets/XPC_Architectural_Support_for_Secure_and_Efficient_Cross_1 hl-page:: 3 hl-color:: yellow id:: 6456687d-1f7b-4918-942f-78a3c66bdad3 + collapsed:: true - 有很多的 `x-entry` 记录可 IPC 的 procedure，然后有一个ID作为它在表里面的 Index hl-page:: 3 ls-type:: annotation @@ -184,6 +262,7 @@ file-path:: ../assets/XPC_Architectural_Support_for_Secure_and_Efficient_Cross_1 hl-page:: 4 hl-color:: yellow id:: 64566b0b-9fd9-474f-aeea-aa032fbca2d5 + collapsed:: true - 一个 `relay-seg` 是一块 ==物理连续== 的内存 - 内存地址翻译通过新的 reg `seg-reg` 完成，同时`seg-reg`在 caller 和 callee 之间传递，因此 callee 可以直接访问 - OS 需要保证这块物理地址不会被常规的页表映射占用 @@ -256,11 +335,13 @@ file-path:: ../assets/XPC_Architectural_Support_for_Secure_and_Efficient_Cross_1 hl-page:: 5 hl-color:: yellow id:: 64565fc3-b632-4cb5-949e-3f96d9ce5f2f + collapsed:: true - relay-seg ls-type:: annotation hl-page:: 5 hl-color:: yellow id:: 64567cca-6189-4008-a36e-f04ddfcdbd8c + collapsed:: true - add a register `seg-reg` = `VA | PA | Len | Perm` - prior to TLB, direct-map VA to PA (contiguous physical memory) - `relay-seg` 指的是一块内存，而 `seg-reg` 表示的是一个映射 @@ -269,6 +350,7 @@ file-path:: ../assets/XPC_Architectural_Support_for_Secure_and_Efficient_Cross_1 hl-page:: 5 hl-color:: yellow id:: 64567cc7-b245-4d66-8d32-6c9dec52f0d7 + collapsed:: true - 设计者不希望用户程序直接修改 `seg-reg` 的映射，因此加了一个`seg-mask` 用来把当前进程的 `seg-reg` 切出来一部分再传递 - 主要是用来 invoking chain 的，可能是作者认为这种情况比较常见吧 - Multiple relay-segs @@ -296,7 +378,7 @@ file-path:: ../assets/XPC_Architectural_Support_for_Secure_and_Efficient_Cross_1 hl-color:: yellow id:: 64570679-5acf-4701-b718-f1d3b22d3df7 - 硬件保证 `seg-reg` 在 `xret` 的时候和存在 `linkage-record` 里面的是一致的 - - 奇妙的安全检查机制 + - 因为如果callee是恶意软件,那它可能会把一个别的seg-reg给塞给caller,如果caller不检查可能会出问题. 因为seg-reg好像只能软件改 - emmm，它好像没说怎么创建这些东西的接口？ - 4 IMPLEMENTATION ls-type:: annotation @@ -308,6 +390,7 @@ file-path:: ../assets/XPC_Architectural_Support_for_Secure_and_Efficient_Cross_1 hl-page:: 5 hl-color:: yellow id:: 64571250-753f-4f6c-b402-926ef4594c06 + collapsed:: true - XPC Engine ls-type:: annotation hl-page:: 5