Memory Safe Inline Assembly

2 comments

• IAmLiterallyAB0 minutes ago
  I wonder if an adversarial user could bypass the checks and achieve memory corruption &#x2F; code execution. Maybe not a practical attack in most situations but a fun exercise.<p>&gt; This includes things like asm volatile(&quot;&quot; : : : &quot;memory&quot;), which is an old-school way of saying atomic_signal_fence(memory_order_seq_cst).<p>Not quite. AIUI, the first is just a barrier for the compiler, while the second is also a CPU memory barrier. Godbolt seems to confirm that.<p><a href="https:&#x2F;&#x2F;godbolt.org&#x2F;z&#x2F;a844zKej8" rel="nofollow">https:&#x2F;&#x2F;godbolt.org&#x2F;z&#x2F;a844zKej8</a>
• jdw6420 minutes ago
  What is more frightening about this than safe C assembly is that this level of implementation is achievable not with a SOTA model, but with a cost effective model like KIMI. There was human judgment involved in the middle, but reading the article, My reading of the process is as follows:<p>1.A developer identified the necessity of inline assembly.<p>2.Defined the safety boundaries for &#x27;memory-safe&#x27; inline assembly.<p>3.Established strict policies for memory access.<p>4.Curated an allowlist of permissible instructions.<p>5.Set rigorous test criteria and &#x27;done&#x27; conditions.<p>In short, with the overall guardrails in place, a sub agent loop was run, and this level of code was produced. This raises a number of interesting points about how we should use AI. I haven&#x27;t looked at all the code, but the idea of passing assembly through safe zones without memory access, and using that as a foundation to achieve this level of implementation through AI, is quite impressive