MiraclePtr update and deployment plan

Bartek Nowierski

unread,

Nov 2, 2021, 3:41:36 AM11/2/21

to Chromium-dev, [email protected], Keishi Hattori, Kentaro Hara, Bartek Nowierski

[ crossposting to chromium-dev@ & memory-safety-dev@ ]

TL;DR; MiraclePtr (aka. BackupRefPtr) results are looking very promising and we anticipate to rewrite many T* pointers in Chromium to raw_ptr<T> in the not-too-distant future.

MiraclePtr is our response to Chromium's biggest security problem, i.e. a constant stream of exploitable (and exploited) Use-after-Free bugs. The algorithm we've chosen (BackupRefPtr) is based on quarantining freed memory that has known pointer references. There may be a performance cost associated with this protection, which is currently under evaluation. We will send a separate announcement with performance/memory numbers and developer guidelines before making any non-trivial changes to the Chromium code base.

The plan is as follows:

Evaluate perf/memory overhead of MiraclePtr that can't be tested via field trials using binary A/B experiments.

If looking good, land the so-called "Big Rewrite", which automatically converts almost all class/struct fields from T* to raw_ptr<T>, throughout Chromium (exclusions apply, the most notable one being Renderer-only code). The MiraclePtr protection will be disabled at run-time, at first.

Evaluate perf/memory overhead that can be tested using field trials.

If looking good, enable MiraclePtr protection. Windows and Android will come first, the other platforms to follow.

Enable clang plugin that will enforce that no new raw pointer fields are added. (There will be a per-pointer option to opt-out, if needed.)

We're currently deep in step #1, which presents unique technical difficulties and challenges. But the results from Windows that we've seen so far make us feel very optimistic. We're working actively on getting Android results, and hoping to proceed with #2 in the near future.

What this means for Chromium developers is that you'll then have to follow these rules (still draft). We tried to make them as simple as possible, and in 99% cases you can just use raw_ptr<T> instead of T* without thinking about it. At first, these rules won't be fully enforced, until we reach step #5.

Best regards,

Bartek Nowierski

Google, Chrome Memory Tokyo Team

Bartek Nowierski

unread,

Nov 2, 2021, 3:46:38 AM11/2/21

to Chromium-dev, [email protected], Keishi Hattori, Kentaro Hara

Sylvain Defresne

unread,

Nov 5, 2021, 8:45:27 PM11/5/21

to [email protected], Chromium-dev, [email protected], Keishi Hattori, Kentaro Hara

Hello,

I've looked at the document and I don't see any reference to pointers to Objective-C objects. I assume that this is something that has been considered by your team (and they are mentioned in some threads). It would be good to have the rule for pointers to Objective-C objects be documented too, whether it is to say that raw_ptr<T> works for a pointer to an Objective-C objects, or to say that they are exempt from the interdiction of raw pointers.

Code used on iOS does use Objective-C heavily, and builds with Automatic Reference Counting (ARC) enabled, thus we do not have smart pointers to wrap those pointers to Objective-C objects (as opposed to macOS which does not enable ARC). Code on iOS also extensively use __weak and __strong annotation on those pointers, and I'm not sure how they would interact with raw_ptr<T>.

Cheers,

-- Sylvain

--
--
Chromium Developers mailing list: [email protected]
View archives, change email options, or unsubscribe:
https://groups.google.com/a/chromium.org/group/chromium-dev
---
You received this message because you are subscribed to the Google Groups "Chromium-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [email protected].
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-dev/CA%2B%2B_KbQr9Yb7c4HQJyKYk7wAjyQ_dxyjYOWemG1bTwNssZVBWw%40mail.gmail.com.

Bartek Nowierski

unread,

Nov 10, 2021, 11:58:18 AM11/10/21

to Sylvain Defresne, Chromium-dev, [email protected], Keishi Hattori, Kentaro Hara, Bartek Nowierski

Thanks for reminding! You're right, we didn't get a good job thinking about pointers to Objective-C objects, and I'll be looking closer into this. Let's stay in touch!

Cheers,

Bartek

Bartek Nowierski

unread,

Dec 23, 2021, 11:38:26 AM12/23/21

to Chromium-dev, [email protected], Asesh Shrestha, Keishi Hattori, Kentaro Hara, Bartek Nowierski

Hello all,

A quick update on recent developments...

Having demonstrated that the overhead that can't be tested via field trials is acceptable, we landed the Big Rewrite over the Thanksgiving weekend: crrev.com/c/3305132 & crrev.com/c/3305633.

This enabled us to start field trials in M98 (currently in Dev). It's a multi-leg experiment, where one leg enables BackupRefPtr only in Browser, and another leg in all processes except for Renderer. Furthermore, in M99 (currently in Canary), we started an experiment with a different variant of BackupRefPtr, which has different perf characteristics and is expected to use less memory.

Cheers,

Bartek

[email protected]

unread,

Jun 30, 2022, 4:35:29 PM6/30/22

to Bartek Nowierski, Chromium-dev, [email protected], Asesh Shrestha, Keishi Hattori, Kentaro Hara

Hello,

We now have raw_ref<T> available which is a reference wrapper with the same UAF protections as raw_ptr. Please use this in place of raw_ptr when the pointer would never be null. You can use a `const raw_ref<T>` if the reference should not be rebindable, and a `raw_ref<const T>` if the object itself is const, or a combination of the two.

Cheers,

Dana

--
You received this message because you are subscribed to the Google Groups "memory-safety-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [email protected].
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/memory-safety-dev/CA%2B%2B_KbQfj2JUn63tcLYr3FJLv0Gd6Y_SKoXpNYSdXb2joYQUFw%40mail.gmail.com.
For more options, visit https://groups.google.com/a/chromium.org/d/optout.

Reply all

Reply to author

Forward