[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"article-bento-webassembly-memory-compartments-en":3,"article-related-bento-webassembly-memory-compartments-en":30,"series-research-e17d7e2f-2b15-493b-9bed-fe95abc7a20d":83},{"id":4,"slug":5,"title":6,"content":7,"summary":8,"source":9,"source_url":10,"author":11,"image_url":12,"cover_image":12,"category":13,"language":14,"translated_content":11,"related_article_id":15,"keywords":16,"key_takeaways":22,"views":26,"created_at":27,"published_at":28,"topic_cluster_id":29},"e17d7e2f-2b15-493b-9bed-fe95abc7a20d","bento-webassembly-memory-compartments-en","Bento turns WebAssembly memory into compartments","\u003Cp data-speakable=\"summary\">Bento isolates WebAssembly memory so browser apps can survive buffer overflows.\u003C\u002Fp>\u003Cp>I've been following WebAssembly security for a while, and honestly, the story keeps repeating itself: we keep moving native-ish code into the browser, then acting surprised when old C and C++ memory bugs come along for the ride. That’s the part that always annoys me. The app loads fast, the demo looks great, and then one sloppy bounds check can turn into a browser-side mess that nobody wanted. I’ve seen teams try to fix this with source-code rewrites, runtime hardening, or some browser-specific setup that works beautifully in a lab and falls apart the minute you try to ship it broadly.\u003C\u002Fp>\u003Cp>So when I saw a paper that basically says, “don’t rewrite the app, just reorganize its memory automatically,” I paid attention. That’s a much more realistic pitch. The whole point of WebAssembly was to get serious software into the browser without the usual install pain, not to force every vendor into a security refactor marathon. The interesting part here is not that memory safety matters. We already know that. It’s that the researchers are trying to fix the problem at the binary level, after compilation, and still keep the user experience boring in the best possible way.\u003C\u002Fp>\u003Cp>The trigger for this breakdown is TechXplore’s June 5, 2026 article, \u003Ca href=\"https:\u002F\u002Ftechxplore.com\u002Fnews\u002F2026-06-webassembly-memory-layout-heartbleed-style.html\">New WebAssembly memory layout could stop Heartbleed-style browser attacks with no visible slowdown\u003C\u002Fa>, which summarizes work from Oussama Draissi and Prof. Lucas Davi at the University of Duisburg-Essen \u002F paluno. The paper they point to is \u003Ca href=\"https:\u002F\u002Fdl.acm.org\u002Fdoi\u002F10.1145\u002F3774904.3792439\">Bento: Fine-Grained Memory Isolation for COTS WebAssembly Binaries\u003C\u002Fa>, and the hook is simple: they use Wasm’s multi-memory feature to isolate regions without needing source access or custom hardware.\u003C\u002Fp>\u003Ch2>The real problem is not WebAssembly. It’s legacy memory bugs in a new wrapper.\u003C\u002Fh2>\u003Cblockquote>“The researchers use Wasm's multi-memory feature to perform a one-time, fully automated memory reorganization of existing modules.”\u003C\u002Fblockquote>\u003Cp>What this actually means is that the security issue isn’t some exotic WebAssembly flaw. It’s the same old C\u002FC++ memory corruption problem, just packaged as a Wasm module and running in a browser. If the original code has a buffer overflow, that bug can still scribble over adjacent data unless something keeps the memory regions apart.\u003C\u002Fp>\n\u003Cfigure class=\"my-6\">\u003Cimg src=\"https:\u002F\u002Fxxdpdyhzhpamafnrdkyq.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fcovers\u002Finline-1780811290637-auhc.png\" alt=\"Bento turns WebAssembly memory into compartments\" class=\"rounded-xl w-full\" loading=\"lazy\" \u002F>\u003C\u002Ffigure>\n\u003Cp>The article makes that point pretty plainly: applications like Photoshop, Zoom, Twitch, or \u003Ca href=\"\u002Ftag\u002Fgoogle\">Google\u003C\u002Fa> Earth can run in the browser because Wasm compiles native code into a format browsers understand. But if the source code was unsafe before compilation, Wasm doesn’t magically cleanse it. I’ve had people assume “it’s in the browser now, so it must be safer.” No. The browser is just the delivery vehicle. The bug still gets a seat.\u003C\u002Fp>\u003Cp>How to apply it: if you’re shipping Wasm binaries built from memory-unsafe code, stop treating the browser as the fix. Treat the binary as suspect and add a post-compilation isolation step. If you own the source, great, you can still harden there too. But if you don’t, or if you’re dealing with third-party modules, you need a defense that works after the fact.\u003C\u002Fp>\u003Cul>\u003Cli>Assume compiled Wasm can still carry over buffer overflows and out-of-bounds writes.\u003C\u002Fli>\u003Cli>Separate “running in WebAssembly” from “memory safe.” Those are not the same thing.\u003C\u002Fli>\u003Cli>Prefer defenses that can operate on binaries, not just source trees.\u003C\u002Fli>\u003C\u002Ful>\u003Ch2>Multi-memory is the boring feature that makes this idea work\u003C\u002Fh2>\u003Cblockquote>“They use Wasm's multi-memory feature to perform a one-time, fully automated memory reorganization of existing modules.”\u003C\u002Fblockquote>\u003Cp>What this actually means is that the module no longer treats memory as one big shared slab. Instead, the layout gets split into compartments. That matters because a lot of exploitation depends on adjacent data being adjacent for a reason. If the attacker can overflow one region into another, they can often corrupt control data, HTML content, or other sensitive state.\u003C\u002Fp>\u003Cp>I like this approach because it’s not trying to invent a new security model from scratch. It’s using a feature that already exists in the WebAssembly standard: multi-memory. That makes the story much less hand-wavy. The security win comes from rearranging the module so different data categories stop living on top of each other like a pile of loose cables.\u003C\u002Fp>\u003Cp>The TechXplore piece compares the layout to a Japanese bento box, and that metaphor is actually useful for once. You don’t want your rice, pickles, and protein all spilling into each other. Same idea here: if HTML tags, buffers, and other data live in separate compartments, an overflow in one part is less likely to poison everything else.\u003C\u002Fp>\u003Cp>How to apply it: audit your Wasm modules for high-risk data zones. If you’re building tooling, think in terms of classification first, layout second. The point is not just “more memories.” The point is “the right data should not be physically adjacent to the wrong data.”\u003C\u002Fp>\u003Cul>\u003Cli>Group sensitive state separately from attacker-influenced buffers.\u003C\u002Fli>\u003Cli>Use compartmentalization to limit what a single overflow can reach.\u003C\u002Fli>\u003Cli>Prefer automated layout rules over manual one-off memory maps.\u003C\u002Fli>\u003C\u002Ful>\u003Ch2>Why this is better than the usual security theater\u003C\u002Fh2>\u003Cblockquote>“Existing approaches to securing Wasm modules are hardly practical.”\u003C\u002Fblockquote>\u003Cp>That sentence is doing a lot of work, and I agree with it. A lot of security ideas are technically neat and operationally useless. Some require source code, which you often don’t have if you’re dealing with commercial off-the-shelf software. Some need special hardware. Some need a custom browser. And once you ask a deployment team to change the browser, the hardware, and the source pipeline, you’ve basically asked them to stop shipping.\u003C\u002Fp>\n\u003Cfigure class=\"my-6\">\u003Cimg src=\"https:\u002F\u002Fxxdpdyhzhpamafnrdkyq.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fcovers\u002Finline-1780811289647-5kkb.png\" alt=\"Bento turns WebAssembly memory into compartments\" class=\"rounded-xl w-full\" loading=\"lazy\" \u002F>\u003C\u002Ffigure>\n\u003Cp>What this actually means is that the best security control is the one you can actually deploy. The researchers are aiming at COTS applications, which is the right target. Real-world browser apps are not clean research toys. They’re binaries from vendors, libraries from elsewhere, and build chains nobody wants to touch unless they absolutely have to.\u003C\u002Fp>\u003Cp>I’ve been burned by “secure by design” plans that quietly depended on everyone rewriting everything. That’s not a plan. That’s a wish. This paper’s pitch is much more grounded: take the compiled module, automatically reorganize memory, and leave the rest alone.\u003C\u002Fp>\u003Cp>How to apply it: if you maintain a platform or browser-adjacent runtime, ask whether your mitigation depends on developer cooperation. If the answer is yes, expect adoption pain. If you’re building a tool like this, make binary-only support and zero app changes the default requirement, not a nice-to-have.\u003C\u002Fp>\u003Ch2>Heartbleed is the right nightmare to use here\u003C\u002Fh2>\u003Cblockquote>“The researchers tested the effectiveness of the bento approach using known security vulnerabilities, including the infamous Heartbleed bug.”\u003C\u002Fblockquote>\u003Cp>What this actually means is they didn’t just wave at a toy overflow and call it a day. Heartbleed is the kind of name that instantly communicates “this is not theoretical.” It’s a memory disclosure bug people remember because it was ugly, widespread, and painfully real. If a layout defense can block something in that class, the claim gets much more interesting.\u003C\u002Fp>\u003Cp>The article says the team demonstrated that their solution would have successfully defended against real-world attacks on widely used applications. That’s the part I care about. Not whether the idea sounds elegant, but whether it survives contact with familiar failure modes.\u003C\u002Fp>\u003Cp>I ran into a similar pattern when reviewing sandboxing work years ago: if your demo only beats contrived payloads, nobody serious trusts it. But if it handles a bug class people already know how to exploit, you’ve got something worth discussing. The bar is simple: can it stop the same old memory mistakes from turning into browser-side compromise?\u003C\u002Fp>\u003Cp>How to apply it: \u003Ca href=\"\u002Ftag\u002Fbenchmark\">benchmark\u003C\u002Fa> your defenses against named, documented exploit classes, not just synthetic overflow tests. If you’re evaluating a Wasm security tool, ask whether it has been checked against disclosure bugs, not only crash bugs.\u003C\u002Fp>\u003Ch2>No visible slowdown is the part that decides adoption\u003C\u002Fh2>\u003Cblockquote>“They will notice neither longer loading times nor a significantly larger memory footprint.”\u003C\u002Fblockquote>\u003Cp>What this actually means is that the security story is only half the story. If the mitigation makes the app feel heavier, slower, or hungrier, it gets quietly rejected. Users don’t care that the defense is elegant if the app now takes longer to open and chews more memory on every tab.\u003C\u002Fp>\u003Cp>This is the piece that caught my eye. Security research often spends all its energy proving the attack stops, then shrugs at the cost. But in browser software, cost is the whole game. You can’t hide latency. You can’t hide memory bloat. If the user notices, the feature is already in trouble.\u003C\u002Fp>\u003Cp>The article says the researchers saw no noticeable drawbacks in loading time or memory footprint. I’m taking that as a strong but still research-stage claim, not a blanket guarantee. Still, it matters because it addresses the first objection any product team will raise: “What does this break?” If the answer is “not much,” adoption gets a lot easier.\u003C\u002Fp>\u003Cp>How to apply it: if you’re designing a hardening pass, measure startup time, resident memory, and steady-state overhead from day one. Don’t bolt performance testing on at the end. If the security win costs a visible slowdown, you need a different design.\u003C\u002Fp>\u003Ch2>This is really a binary-hardening playbook, not a WebAssembly trick\u003C\u002Fh2>\u003Cblockquote>“One-time, fully automated memory reorganization of existing modules.”\u003C\u002Fblockquote>\u003Cp>What this actually means is that the bigger idea here is not “WebAssembly can do a cute thing.” The bigger idea is that compiled software can be post-processed into a safer shape without source changes. That’s the part I’d want people to notice.\u003C\u002Fp>\u003Cp>This could matter anywhere you have third-party binaries that you can’t realistically rebuild. WebAssembly is just the current proving ground because browsers make the memory boundary visible and painful. But the general pattern is bigger: inspect the binary, classify the memory, split the dangerous parts apart, and keep the runtime changes minimal.\u003C\u002Fp>\u003Cp>I like tools that respect deployment reality. If a defense only works in a perfect greenfield stack, I mentally file it under “interesting, maybe later.” If it can wrap around existing software and make it harder to exploit without turning operations into a science project, then we’re talking about something usable.\u003C\u002Fp>\u003Cp>How to apply it: when you evaluate hardening tech, ask three questions. Can it work without source? Can it work without custom hardware? Can it work without changing the user’s browser or workflow? If the answer to any of those is no, expect friction.\u003C\u002Fp>\u003Ch2>The template you can copy\u003C\u002Fh2>\u003Cpre>\u003Ccode># Bento-style WebAssembly hardening checklist\n\n## Goal\nAutomatically isolate risky memory regions in a WebAssembly binary so a buffer overflow in one region cannot overwrite unrelated data.\n\n## When to use it\n- You ship C\u002FC++ code compiled to Wasm\n- You do not fully trust the module’s memory safety\n- You need a defense that works without source changes\n- You want to avoid custom browsers or special hardware\n\n## Core idea\n1. Inspect the compiled Wasm module.\n2. Identify memory regions by risk and data type.\n3. Reorganize the module to use separate memories or compartments.\n4. Keep attacker-influenced buffers away from sensitive state.\n5. Validate that the new layout does not add visible runtime cost.\n\n## Layout rules\n- Put untrusted input buffers in their own compartment.\n- Keep HTML, script-like content, and control data separated.\n- Do not place sensitive pointers next to overflow-prone arrays.\n- Prefer automatic grouping over manual tuning.\n\n## Security checks\n- Test against known memory disclosure bugs.\n- Test against buffer overflow payloads.\n- Verify that corruption in one compartment cannot reach another.\n- Measure startup time and memory footprint after reorganization.\n\n## Deployment questions\n- Does it work on existing binaries?\n- Does it avoid source-code changes?\n- Does it avoid browser modifications?\n- Does it avoid special hardware?\n- Does it keep overhead low enough to ship?\n\n## Copy-paste policy note\nWe harden compiled WebAssembly modules by isolating memory regions so a single overflow cannot corrupt unrelated data. If the module cannot be safely compartmentalized, it does not ship until the layout is fixed.\n\u003C\u002Fcode>\u003C\u002Fpre>\u003Cp>That’s the version I’d hand to a team that needs the idea, not the paper prose. It won’t implement Bento for you, but it captures the operating principle: compartmentalize memory, keep the deployment surface boring, and test against real exploit classes.\u003C\u002Fp>\u003Cp>Source attribution: I based this breakdown on TechXplore’s article at \u003Ca href=\"https:\u002F\u002Ftechxplore.com\u002Fnews\u002F2026-06-webassembly-memory-layout-heartbleed-style.html\">https:\u002F\u002Ftechxplore.com\u002Fnews\u002F2026-06-webassembly-memory-layout-heartbleed-style.html\u003C\u002Fa> and the linked ACM paper \u003Ca href=\"https:\u002F\u002Fdl.acm.org\u002Fdoi\u002F10.1145\u002F3774904.3792439\">Bento: Fine-Grained Memory Isolation for COTS WebAssembly Binaries\u003C\u002Fa>. The framing, interpretation, and template above are my own synthesis.\u003C\u002Fp>","A new WebAssembly memory layout isolates risky data into compartments so browser apps resist Heartbleed-style bugs without visible slowdown.","techxplore.com","https:\u002F\u002Ftechxplore.com\u002Fnews\u002F2026-06-webassembly-memory-layout-heartbleed-style.html",null,"https:\u002F\u002Fxxdpdyhzhpamafnrdkyq.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fcovers\u002Finline-1780811290637-auhc.png","research","en","174a1d04-6330-4ed1-98d3-32a6199d2108",[17,18,19,20,21],"WebAssembly","browser security","memory isolation","binary hardening","Heartbleed",[23,24,25],"Bento reorganizes compiled Wasm memory instead of requiring source changes.","The defense aims to block overflow-driven attacks by isolating compartments.","The practical win is low-friction deployment with no noticeable slowdown.",0,"2026-06-07T05:47:46.129275+00:00","2026-06-07T05:47:46.118+00:00","3103988e-c4fe-45e3-98ab-846500c9d507",{"tags":31,"relatedLang":42,"relatedPosts":46},[32,34,36,38,40],{"name":19,"slug":33},"memory-isolation",{"name":17,"slug":35},"webassembly",{"name":20,"slug":37},"binary-hardening",{"name":18,"slug":39},"browser-security",{"name":21,"slug":41},"heartbleed",{"id":15,"slug":43,"title":44,"language":45},"bento-webassembly-memory-compartments-zh","Bento 把 Wasm 記憶體切成隔間","zh",[47,53,59,65,71,77],{"id":48,"slug":49,"title":50,"cover_image":51,"image_url":51,"created_at":52,"category":13},"99349700-bdd6-4a02-9354-17ff20598452","bis-stablecoin-usable-buffers-regulation-en","BIS turns stablecoin rules into usable buffers","https:\u002F\u002Fxxdpdyhzhpamafnrdkyq.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fcovers\u002Finline-1780737504361-by41.png","2026-06-06T09:17:56.826856+00:00",{"id":54,"slug":55,"title":56,"cover_image":57,"image_url":57,"created_at":58,"category":13},"5cf69bca-6c4c-46e0-a4b7-b0a59835c548","prevent-catastrophic-forgetting-llm-fine-tuning-en","How to Prevent Catastrophic Forgetting in LLM Fine-Tuning","https:\u002F\u002Fxxdpdyhzhpamafnrdkyq.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fcovers\u002Finline-1780730282480-iwp2.png","2026-06-06T07:17:32.623791+00:00",{"id":60,"slug":61,"title":62,"cover_image":63,"image_url":63,"created_at":64,"category":13},"092a851e-da2c-45f9-a550-d9db620ebb1b","code2lora-repo-specific-adapters-code-models-en","Code2LoRA generates repo-specific adapters","https:\u002F\u002Fxxdpdyhzhpamafnrdkyq.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fcovers\u002Finline-1780727590988-xe8t.png","2026-06-06T06:32:46.445714+00:00",{"id":66,"slug":67,"title":68,"cover_image":69,"image_url":69,"created_at":70,"category":13},"cb4d09b6-0301-417e-8b84-11cd25ff4ae1","handoff-humanoid-control-planner-friendly-en","HANDOFF makes humanoid control more planner-friendly","https:\u002F\u002Fxxdpdyhzhpamafnrdkyq.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fcovers\u002Finline-1780726685246-4vq8.png","2026-06-06T06:17:35.816558+00:00",{"id":72,"slug":73,"title":74,"cover_image":75,"image_url":75,"created_at":76,"category":13},"c4d4f32b-39fc-42bf-94b0-1dd531c4973f","taillor-protects-key-directions-continual-finetuning-en","TailLoR protects key directions in continual finetuning","https:\u002F\u002Fxxdpdyhzhpamafnrdkyq.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fcovers\u002Finline-1780725795119-uimo.png","2026-06-06T06:02:30.230937+00:00",{"id":78,"slug":79,"title":80,"cover_image":81,"image_url":81,"created_at":82,"category":13},"1848b0d4-2c8a-4c24-928b-46f0ddb4dbb2","why-benchmark-leaderboards-are-wrong-about-model-logic-en","Why benchmark leaderboards are wrong about model logic","https:\u002F\u002Fxxdpdyhzhpamafnrdkyq.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fcovers\u002Finline-1780673573292-rj31.png","2026-06-05T15:32:23.511842+00:00",[84,89,94,99,104,109,114,119,124,129],{"id":85,"slug":86,"title":87,"created_at":88},"a2715e72-1fe8-41b3-abb1-d0cf1f710189","ai-predictions-2026-big-changes-en","AI Predictions for 2026: Brace for Big Changes","2026-03-26T01:25:07.788356+00:00",{"id":90,"slug":91,"title":92,"created_at":93},"8404bd7b-4c2f-4109-9ec4-baf29d88af2b","ml-papers-of-the-week-github-research-desk-en","ML Papers of the Week Turns GitHub Into a Research Desk","2026-03-27T01:11:39.480259+00:00",{"id":95,"slug":96,"title":97,"created_at":98},"87897a94-8065-4464-a016-1f23e89e17cc","ai-ml-conferences-to-watch-in-2026-en","AI\u002FML Conferences to Watch in 2026","2026-03-27T01:51:54.184108+00:00",{"id":100,"slug":101,"title":102,"created_at":103},"6f1987cf-25f3-47a4-b3e6-db0997695be8","openclaw-agents-manipulated-self-sabotage-en","OpenClaw Agents Can Be Manipulated Into Failure","2026-03-28T03:03:18.899465+00:00",{"id":105,"slug":106,"title":107,"created_at":108},"a53571ad-735a-4178-9f93-cb09b699d99c","vega-driving-language-instructions-en","Vega: Driving with Natural Language Instructions","2026-03-28T14:54:04.698882+00:00",{"id":110,"slug":111,"title":112,"created_at":113},"a34581d6-f36e-46da-88bb-582fb3e7425c","personalizing-autonomous-driving-styles-en","Drive My Way: Personalizing Autonomous Driving Styles","2026-03-28T14:54:26.148181+00:00",{"id":115,"slug":116,"title":117,"created_at":118},"2bc1ad7f-26ce-4f02-9885-803b35fd229d","training-knowledge-bases-writeback-rag-en","Training Knowledge Bases with WriteBack-RAG","2026-03-28T14:54:45.643433+00:00",{"id":120,"slug":121,"title":122,"created_at":123},"71adc507-3c54-4605-bbe2-c966acd6187e","packforcing-long-video-generation-en","PackForcing: Efficient Long-Video Generation Method","2026-03-28T14:55:02.646943+00:00",{"id":125,"slug":126,"title":127,"created_at":128},"675942ef-b9ec-4c5f-a997-381250b6eacb","pixelsmile-facial-expression-editing-en","PixelSmile Framework Enhances Facial Expression Editing","2026-03-28T14:55:20.633463+00:00",{"id":130,"slug":131,"title":132,"created_at":133},"6954fa2b-8b66-4839-884b-e46f89fa1bc3","adaptive-block-scaled-data-types-en","IF4: Smarter 4-Bit Quantization That Adapts to Your Data","2026-03-31T06:00:36.65963+00:00"]