 |
yuguorui96 |
yuguorui96 最近回复了
| 回复了 paranoiagu 创建的主题 › 旁路由 ipv6 怎么解决？2023 年 6 月 12 日 |
推荐下我自己用 rust 写的分流程序吧（仅支持分流，不含加密算法）： https://github.com/yuguorui/rfor
- 原生支持 IPv6 及其分流
- 针对 NAS 或 PT 环境，直连时支持源地址保留（即访问 IPv6 网站时如果是直连，那么会直接使用你设备的原有的 IPv6 地址，而不是路由器的）
- 零拷贝支持
- 自动设置 iptables 规则，退出时自动清除规则
- 原生支持 IPv6 及其分流
- 针对 NAS 或 PT 环境，直连时支持源地址保留（即访问 IPv6 网站时如果是直连，那么会直接使用你设备的原有的 IPv6 地址，而不是路由器的）
- 零拷贝支持
- 自动设置 iptables 规则，退出时自动清除规则
| 回复了 busterian 创建的主题 › 2023 年，你们注销淘宝/支付宝账号了吗2023 年 5 月 31 日 |
@musi 利用 0day 这事情真的是记一辈子，不敢安装，真的是比我还了解我的手机。
| 回复了 Nazz 创建的主题 › GNOME 主题分享2023 年 5 月 27 日 |
@Nazz 也许你直接看 Gnome 的 doc 就 OK ？ fedora 和 Ubuntu 不一样，桌面应该很接近 upsteram 才对。
| 回复了 huangya 创建的主题 › Linux 内核一个系列多个 patch 问题2023 年 1 月 9 日 |
The hard way is usually the right way.
没有简单的方法，你需要理解当前的 feature 的工作原理，并评估当前 feature 的依赖依赖是否完备。
当依赖不完备是你需要考虑：是否需要引入新的 upstream patch ，还是用老的 API 实现 feature 所需要的逻辑等；
实现过程中可能还需要你不断迭代，直至你找齐所有的拼图。
邮件列表是一个参考，而不是一个答案。如何能根据快速的评估所需要的 patch 是你“不可替代”的要素之一。
没有简单的方法，你需要理解当前的 feature 的工作原理，并评估当前 feature 的依赖依赖是否完备。
当依赖不完备是你需要考虑：是否需要引入新的 upstream patch ，还是用老的 API 实现 feature 所需要的逻辑等；
实现过程中可能还需要你不断迭代，直至你找齐所有的拼图。
邮件列表是一个参考，而不是一个答案。如何能根据快速的评估所需要的 patch 是你“不可替代”的要素之一。
| 回复了 amiwrong123 创建的主题 › 怎么理解用 TSS 恢复任务的执行，里面用到的 LDT 段选择子？2022 年 12 月 20 日 |
@amiwrong123 你再看看上个回答？谜底就在谜面上。
| 回复了 amiwrong123 创建的主题 › 怎么理解用 TSS 恢复任务的执行，里面用到的 LDT 段选择子？2022 年 12 月 20 日 |
愚以为直接存基址的话，在 32 和 64 之间就需要不同的大小来操作 ldt ，这个非常痛苦。
所以我理解 selector 的本质作用就是替换掉变长的地址宽度。
所以我理解 selector 的本质作用就是替换掉变长的地址宽度。
| 回复了 Aaron325 创建的主题 › 有没有屏蔽 ipv6 的 dns2022 年 9 月 1 日 |
| 回复了 ins0mn1a 创建的主题 › 求助：想知道一个 host 上有哪些设备支持 DMA 该怎么办啊...2022 年 5 月 11 日 |
@ins0mn1a 你这里 post 出来的代码我还没看，但是大体上的逻辑是：
1. firmware 需要在启动时默认启用 IOMMU remapping ，然后后续的 DMA 请求就被默认禁止了；
2. 后面 firmware/OS 就可以根据需求更新 IOMMU 的 second-level page table 以允许 /吊销设备的 DMA 访问能力。
是否也就意味着该设备不会受到 IOMMU 的保护呢？
====================================
否
这里的细节很多，可以参考： https://www.intel.com/content/dam/develop/external/us/en/documents/intel-whitepaper-using-iommu-for-dma-protection-in-uefi-820238.pdf
1. firmware 需要在启动时默认启用 IOMMU remapping ，然后后续的 DMA 请求就被默认禁止了；
2. 后面 firmware/OS 就可以根据需求更新 IOMMU 的 second-level page table 以允许 /吊销设备的 DMA 访问能力。
是否也就意味着该设备不会受到 IOMMU 的保护呢？
====================================
否
这里的细节很多，可以参考： https://www.intel.com/content/dam/develop/external/us/en/documents/intel-whitepaper-using-iommu-for-dma-protection-in-uefi-820238.pdf
| 回复了 ins0mn1a 创建的主题 › 求助：想知道一个 host 上有哪些设备支持 DMA 该怎么办啊...2022 年 5 月 11 日 |
说的更明白点，如果我是一个已经挂载在总线上的恶意设备，如果我不主动暴露 DMA 能力，没啥好方法探测。
如果你的假设是设备都是诚实的，倒是可以翻翻驱动，看看驱动分配时有没有用 DMA 相关的内存分配 API ，但是这个都只是启发式的。
如果你的假设是设备都是诚实的，倒是可以翻翻驱动，看看驱动分配时有没有用 DMA 相关的内存分配 API ，但是这个都只是启发式的。
| 回复了 ins0mn1a 创建的主题 › 求助：想知道一个 host 上有哪些设备支持 DMA 该怎么办啊...2022 年 5 月 10 日 |
设备支持不支持 DMA 和驱动没有必然联系。
一个设备有 DMA 控制器，能朝系统总线上写 DMA 相关的消息就可以进行 DMA 了（假设我不关心会不会把系统写挂）。以 PIC 为例，DMA 的过程实际就是写 TLP 包的过程，然后就可以通过 PCI 的路由逻辑路由到 DIMM 里了，这个过程和任何驱动有关吗？
一个设备有 DMA 控制器，能朝系统总线上写 DMA 相关的消息就可以进行 DMA 了（假设我不关心会不会把系统写挂）。以 PIC 为例，DMA 的过程实际就是写 TLP 包的过程，然后就可以通过 PCI 的路由逻辑路由到 DIMM 里了，这个过程和任何驱动有关吗？