fix image url && recover lost attachments

Author: PwnTips

_posts/2023-05-07-CVE-2022-1364.md

@@ -75,7 +75,7 @@ console.log(e2.M === e2.C); // should be true as above but prints false.
 
 这样的话在临近位置，连续调用函数 C 返回的应该就是同一层栈帧对应的 this 对象。e2.M === e2.C 应该像注释中描述的也为 true 才对。继续分析 opt 函数的 JIT 编译做了哪些优化，为什么改变了这个结果。
 
-用 ./Chrome.exe --js-flags="--allow-natives-syntax --trace-turbo" --no-sandbox --enable-logging=stderr 命令重新启动 chrome，访问 POC 页面后，得到编译过程的 trace 日志 ![[turbo-000000B00023E8B4-0 1.json]]，用 [v8 turbolizer](https://v8.github.io/tools/head/turbolizer/index.html) 打开
+用 ./Chrome.exe --js-flags="--allow-natives-syntax --trace-turbo" --no-sandbox --enable-logging=stderr 命令重新启动 chrome，访问 POC 页面后，得到编译过程的 trace 日志 ![turbo-000000B00023E8B4-0 1.json](/assets/images/turbo-000000B00023E8B4-0%201.json)，用 [v8 turbolizer](https://v8.github.io/tools/head/turbolizer/index.html) 打开
 
 opt 函数整理一下，可以写成下面的形式：
 ```javascript
@@ -1409,17 +1409,7 @@ int TranslatedState::CreateNextTranslatedValue(
 }
 ```
 
-
-
-```plantuml
-@startuml
-skinparam handwritten true
-[FrameState] -> [FrameDescriptor] : AppendDeoptimizeArguments
-[FrameDescriptor] -> [TranslationArray] : TranslateFrameStateDescriptorOperands
-[TramslationArray] -> [JavascriptFrameSummary] : OptimizedFrame::Summarize
-@enduml
-```
-
+![plantum-diagram](https://www.plantuml.com/plantuml/png/NOz13i8W44Ntd88BU84kJ9iqBjnqeJlJnKGcIkmCP1WqUdffqTIuvF__7j0c1T5Caqatpn44o5w1tKEyAh9LoMXEknBZGK5nj9kjhUSUqrbyr22ZRMmN8xBhCKJrv5_OoIKJiYRplwwAem2d2TG7xaJWEJk-6QxthTWGiTGkcHcbNxGAzt27kgrq9W9PjCFdIMufcgPM9J0jiYj_VmC0)
 
 StateValues
 
@@ -1868,33 +1858,33 @@ void InstructionSelector::VisitCall(Node* node, BasicBlock* handler) {
 
 FrameState 节点是 `BytecodeGraphBuilder` 在生成 turbofan 图 IR 时创建的，用 [turbolizer](https://v8.github.io/tools/head/turbolizer/index.html) 打开 turbofan 输出的 trace 文件，从后往前分析 IR 后发现，`kObjectId` 节点对应的是 `b.a.call(arguments,b)` 函数调用的 FrameState 中的 receiver 参数
 
-![[Pasted image 20230811003541.png]]
+![Pasted image 20230811003541.png](/assets/images/Pasted%20image%2020230811003541.png)
 kObjectId 节点是在 EscapeAnalysis 阶段创建的
-![[Pasted image 20230811003746.png]]
+![Pasted image 20230811003746.png](/assets/images/Pasted%20image%2020230811003746.png)
 
 再看一下 EscapeAnalysis 之前的 LoadElimination 阶段, 对应的位置是一个 kFinishRegion 节点，浏览相关代码后得知这个节点是 `AllocationBuilder` 创建的，是一系列对象创建操作的结尾，结合 POC 源码推测，这里代表的是 arguments 对象的创建。 
 
-![[Pasted image 20230811005830.png]]
+![Pasted image 20230811005830.png](/assets/images/Pasted%20image%2020230811005830.png)
 
 再往前追溯到 Typer 阶段，发现这里变成了 JSCrateArguments 节点，就刚好可以证实之前的推测。
 
 ![[Pasted image 20230814232830.png]]
 
 再往前追溯，下次变化在 BytecodeGraphBuilder 阶段，这个是因为紧随其后的 Inlining 阶段把 JSCall
 
-![[Pasted image 20230815221029.png]]
+![Pasted image 20230815221029.png](/assets/images/Pasted%20image%2020230815221029.png)
 
 从 turbofan 的源码视图也可以看出来两个子函数都被 inline 进了最外层的函数
 
-![[Pasted image 20230815221141.png]]
+![Pasted image 20230815221141.png](/assets/images/Pasted%20image%2020230815221141.png)
 
 在选定好 inline 的目标后，是在 `JSInliner::ReduceJSCall(Node* node)` 函数中完成实际的 inline 操作。主要是创建子函数的 IR 图，之后把它连接到父函数的 IR 图中。连接过程从，有两个操作引起了我的注意：
 - 用调用点 (JSCall节点) 的 FrameState 替换子函数内部的 FrameState 的 outer_frame_state 输入
 - 用调用点 (JSCall节点) 的实参 (inputs) 替代子函数的 形参 (Parameters) 节点
 
 了解了这些再来仔细看下 inline 之后的情况
 
-![[Pasted image 20230816004600.png]]
+![Pasted image 20230816004600.png](/assets/images/Pasted%20image%2020230816004600.png)
 
 此时这个 JSCall 对应的已经是 a.b(0, a) 这个函数调用, 所以这个 FrameState 对应的是
 ```
@@ -2088,13 +2078,13 @@ Reduction JSCreateLowering::ReduceJSCreateArguments(Node* node) {
 
 优化过后 JSCreateArguments 就被展开成了下面这些 Allocate 和 StoreField 节点。
 
-![[Pasted image 20230816223925.png]]
+![Pasted image 20230816223925.png](/assets/images/Pasted%20image%2020230816223925.png)
 
-![[Pasted image 20230816224756.png]]
+![Pasted image 20230816224756.png](/assets/images/Pasted%20image%2020230816224756.png)
 
 之后这个状态一直保持到了逃逸分析 EscapeAnalysis 阶段，在逃逸分析阶段被优化成了下图的样子。
 
-![[Pasted image 20230816232212.png]]
+![Pasted image 20230816232212.png](/assets/images/Pasted%20image%2020230816232212.png)
 
 [逃逸分析](https://en.wikipedia.org/wiki/Escape_analysis)是一种编译优化手段，简单来说如果编译器分析出一个对象只在某个范围内，例如一个函数内部，被创建并使用，那么就可以对它进行一些优化，例如本来应该在堆上分配的对象，如果只在函数内部使用就可以优化到栈上，这种情况可以称为被捕获。反过来如果编译器不能分析出对象只在特定范围内被使用，就可以说对象是逃逸的。推测是编译器分析出 arguments 对象只在函数内部使用，所以对它进行了一些优化。