<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Spectre</title><link>https://blog.ast.moe/en/tags/spectre/</link><description>Recent posts: Gorimuchu</description><generator>Hugo</generator><item><title>Finally understanding Spectre: SharedArrayBuffer was dangerous in a different way than I thought</title><link>https://blog.ast.moe/en/blog/2026-10-16/</link><pubDate>Fri, 16 Oct 2026 21:37:01 +0900</pubDate><guid>https://blog.ast.moe/en/blog/2026-10-16/</guid><description>&lt;p&gt;I already knew that SharedArrayBuffer was unavailable by default in browsers as a mitigation for Spectre. But my understanding of Spectre stopped at a vague idea of a memory-related vulnerability.&lt;/p&gt;
&lt;p&gt;SharedArrayBuffer was a low-level API for shared memory, so I assumed it enabled some kind of memory exploit. I left it at that, without being able to explain how Spectre worked or how an attack used this API.&lt;/p&gt;
&lt;p&gt;Finally reading about it revealed a different problem. SharedArrayBuffer did not directly let you read somebody else&amp;rsquo;s memory. &lt;strong&gt;Shared memory could build a precise clock.&lt;/strong&gt;&lt;/p&gt;</description></item></channel></rss>