Skip to content

2026 Memory Safety in WebKit

Jump to bottom Edit New page
Manuel Rego edited this page Jul 15, 2026 · 1 revision

WEH 2026 - Memory Safety in WebKit

Presentation

  • Wunsafe-buffer-usage clang
  • STL runtime checks
  • UAFs
    • E.g. Foo::Bar() { executeJsThatMightDeleteThis(); member->baz() /* unsafe, this is dangling */ }
    • Smart Ptr: unique_ptr, RefPtr that embeds the refcnt in the object itself, CheckedPtr zeroes out ptr when held object is destructed, WeakPtr, RetainPtr for Apple's platform objects
  • Rules for Safety
    • An argument of a function should be kept alive by its caller
    • A local/member variable must be a smart pointer
    • ??
  • nodelete function annotation
  • LLM helped deploy these tools in a couple of months
  • Future plans: "borrowing", thread safety, ANGLE, libwebrtc

Questions

  • Any statistics about how these changes are improving the number of security issues that are being observed or raised?

  • It's difficult to get these figures, this data. We're seeing security bugs that are already being fixed by these changes.

  • We did a security analysis a few years ago, and another one recently, and it's improved

  • We don't have a feeling of the rate of CVEs

  • Q: Can you tell us more about plans for thread safety?

  • How does this overlap with the ideas of moving parts of WebCore with Swift? How's the integration of Swift and code analysers? What are obvious gaps?

  • A: (Overview of WebKit components, WebCore, WebKit, WTF) Right now, adopting smart pointers and security: WebKit. Plans to adopt too WebCore, but that's a next step. Interested in deploying them there, but not rushing, because WebCore is perf sensitive, and vast majority of code is C++, intertwined with rest of code base. Goal is make it so that you can write more code in WebKit layer in Swift, safety guarantees are fully functional, before start deploying WebCore. Basically when we have Swift-C++ interop, certain constructs not available in Swift, we have "unsafe" construct. We've written backend for WebGPU in Swift, we're addressing interoperability with C++, priority is addressing these issues, make it ready for product adoption. Does it answer?

  • Yes

  • Q: WK distributor. Have a request. This work has been going on year and a half. My request: I'd like for you all to put consideration into opportunity cost. The cost benefit analysis of this. You don't have a huge amount of evidence to document the benefit. The orthodox pov these days is that memory safety is the most important thing, absolutely necessary. But this is substracting from other work that could be going on, a small-ish team and small-ish amount of reviewers, limited, which could be implementing WebPlatform features, reviewing patches from contributors. I'd say it's time to assess continued prioritisation of this relative to the rest of things you could be working on. Not a criticism. It'd be good to have some evidence, and to see some resources pulled off, allocated to Web Platform features

  • A: As stated earlier, there are some evidence that this work has reduced number of security bugs, we have pretty good evidence that this is benefiting WebKit security. In terms of opportunity cost, this might be one of the most important things that we could be working on. For the longest time we have been trying to be careful, but that strategy was not resulting in the security guarantee we want to have, so we want to enforce these rules. we want to get to the point where there are no more warnings at all. All the code would be safe by construct. Checkers verifying this. We would become more productive, because all the code we can write would be safe. We might be reducing the total cost long term. We're betting we could reduce the total number of bugs in the future

  • Q: Yeah, I'm on your side on this, but it feels a bit hand-wavy. You put a lot of rigor into this work and tooling (e.g. the new checker is very useful) but it doesn't seem that the same investment / rigor has been made on making an evaluation of the success of the work, in having a way to measure this. (Realise spending time in making this measurable would also take time from this work, or the web platform work).

  • A: Thanks for the feedback, this is omething we want o be mindful of, we see this as ongoing maintenance in a way. We can deploy new smart pointers very quickly, with LLMs, once we have the chcker. But the checkers themselves can also have bugs which might hide real security bugs. Some of the security bugs has to do with things we haven't had time to deploy smart ptrs to, or issues that the checkers failed to flag because of checker bugs.

  • Q: slide with plan, WebRTC, ANGLE... thread safety. Can you tell us a bit more about thread safety plans, please?

  • A: in terms of thread safety. Denote whether thread safe or not is the first thing. Once we have the annotation, we want to check consistency between objects. Same we do with smart pointer checkers, we check annotations are correct, then we start flagging functions that could send a pointer to one thread to another, make sure all the ptr captures are capturing properly, and we are using some kind of lock. IF you have any idea or suggestion for improvements, we'd love help

  • Q: thanks

  • Q: How can be handle JS object safety with GC. Some object [ missed the question ]

  • A: When we look at JSC bugs are not naive memory safety issue. There are failures to noticy GC something changed. We need a good strategy for this, we want to work on this. This is very high value to achieve a solution here

  • Q: Apparently on September 11 (initially thought to be 2026, turned out to be 2027) site isolation would be required in the EU. Status update on this?

  • A: This year? Wow

  • Q: It's next year. OK. 2027!

  • A: We're hoping to be ready by the next September, we can't really share yet. Working hard on that.

  • Q: How to handle ref cycles? Are you thinking of some static analysis of long chains (e.g. 5-6...)

  • A: Some people have suggested a static analyser for common patterns that could lead to this. We haven't looked yet into this, but it is something that could be explored in the future. There are so many ways to get these leaks. Sometimes people forget to keep GC into account. Keep a JS object alive with JSStrong -- which is almost always the incorrect choice. We want to explore this space, we just haven't had the time to do it.

  • Q: Usage of shared pointers. Have you noticed perf difference since we have ref counting in every object -- e.g. cache misses even if you-re not using an object.

  • A: Perf difference between our custom shared ptr and std (due to where the refcnt is stored)? We did, the custom shared are significantly faster than std. There's contention for ref counting with decrementing and incrementing happening all the time

  • Q: [interrupted by the cruise ship horn]

  • Q: filc which guarantees absolute memory safety. About a month ago built webkit under filc and has it running. What do you think about the possibility to use this as an alternative

  • A: It's an interesting approac. filc uses a vm, and it's challenging to have a VM and then have a JS VM. At some point you need to generate the instructions that JIT can execute, many bugs might lie in there. We see the immediate issue is the JS object rather than whether we can have 100% on the rest of the project. Not sure re interoperability with other languages (e.g. ObjC, Swift).

  • Q: That part (interoperability?) not sure how that's gonna work.

  • Q: with filc you might need to replace JSC, but it would allow using C++ in the entirety of WebKit. Adding new languages increases the bar for new contributors

  • A: Future of Apple platform might be Swift and not Obj-C, maybe. But not sure if that's realistic given how much obj-c there is. When we thought about mem safety is that C++ has too many undefined behaviours where there isn't much guarantee of semantics in terms of how it behaves. It's hard to have the semantics of C++ and a memory safety guarantee. We might need to, in the long term, move away from C++. Remain skeptical of a rewrite

  • Q: We use C++ not for perf but because we like C++. Ref counting and the logic associated gives the compiler a hard time reaosning about what to optimise. While with Swift, that's not the case... Could we do anything here to reduce ref count churn

  • A: WK adopting swift would be a great incentive to optimise Swift perf. People excited that this would give them feedback on what to optimise. The areas were Swift is being adopted aren't that perf sensitive atm.

  • Q: When can I write my (?) in Swift?

  • A: You can already, but not in all platforms

  • Q: How can be better train AI and humans to avoid making mistakes

  • A: Have a tool that tells you when you make a mistake. A static analyser is that kind of tool. LLMs are very good when they are told there's a test that they can iterate with.

  • Q: WebKit Container SDK now containes the Swift toolchain bundle, demo feature and so on. This unblocks the usage of Swift tools on Linux, RPi is our next target. If anybody wants to test, please download the SDK and give it a go

  • A: Thank you for sharing that, that's a very exciting moment

  • Q: A WIP document and scripts to run the static analysis in Linux, a lot overlap with mac but it also finds a lot of things in the LInux specific ports. Maybe we could have EWS bots, that'd be great but takes resources. Soon to be shared

  • A: I think when we brought up safercpp bot, it was only for macos, not ios. Then we brought it for ios and found so many issues.

https://www.webengineshackfest.org/

Add a custom sidebar

Clone this wiki locally