Dawn MiraclePtr Rewrite Completed – Announcement & Explanation

[Arthur Sonzogni]

Dear @dawn-graphic & @memory-safety-dev,

I'm excited to announce that the MiraclePtr rewrite in Dawn (WebGPU) has been completed. 🎉🥳

Most of the rewrite was shipped in M122, with final changes completed in M123

This offers effective protection against UAFs, among other things.

What does this mean in Dawn?

• PartitionAlloc became an optional dependency..

• Member pointers/references within structs/classes have been replaced with raw_ptr<T> / raw_ref<T>

• Dawn's tests utilize the PartitionAlloc allocator and enable the DanglingPointerDetector by default.

The raw_ptr<T> / raw_ref<T> types are designed for use as pointers/references in structs/classes members. They are not typically intended for local variables or function arguments.

For more details, please refer to the Dawn-specific documentation. Please don't hesitate to reach out if you have any questions or encounter specific errors.

What’s next (backlog):

• Enforce raw_ptr<T> usage via the Clang plugin chromium/1504996

• Investigate pre-existing dangling pointers: dawn/2345, dawn/2346, dawn/2348, dawn/2349. 

• Investigate RAW_PTR_EXCLUSION and potential memory safety problems: chromium/1521372, dawn/2365, dawn/2364, dawn/2361

Best regards,

Arthur Sonzogni

[Dominic Cerisano]

So even when hardware memory tagging (MT) is supported in the large (happening now), software MT will still be needed for protecting builds on any unsupported hardware platforms. Is this implementation going to be the fallback if hardware MT is not available on a build target?

Dominic Cerisano

dcer...@gmail.com

NOTICE: Confidential message which may be privileged. Unauthorized use/disclosure prohibited. 
AVIS : Message confidentiel dont le contenu peut être privilégié. Utilisation/divulgation interdites sans permission. 

--
You received this message because you are subscribed to the Google Groups "Dawn Graphics" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dawn-graphic...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/dawn-graphics/CAAzos5GH8Ht6a9e_vbV3ayjksZPcNiYW1kfU6dyvJO%3D%2B3UsARw%40mail.gmail.com.

[Corentin Wallez]

Memory tagging is not widely supported at large yet, and IIRC it can have somewhat high performance costs on the same order as MiraclePtr, as well as worse security guarantees. So MiraclePtr will be on by default even when the platform might support memory tagging. However it is a simple compilation switch to make raw_ptr<T> equivalent to a T* with no additional cost, and it's actually what happens when using Dawn in standalone.

To view this discussion on the web visit https://groups.google.com/d/msgid/dawn-graphics/CA%2BgE_wi2eptV0pypJ8cdnqr%2B6CvjKzJ9tXSFuu0tHeNvyeVrcg%40mail.gmail.com.

[Arthur Sonzogni]

Hi Dominic, I had prepared a very similar answer. Corentin was quicker than me. I'm sharing it anyway for the few links:

Having raw_ptr<T> used by Dawn allows Chrome to swap/tweak the implementation to what fits best today, or whatever will fit better in the future.

• The BackupRefPtr implementation is what shipped on Android, ChromeOS, Windows, Mac and Linux. This is software based. See latest update.

• On supported CPUs, an implementation based on memory tagging extension (MTE) is currently being evaluated. MTE and BackupRefPtr are complementary, so they would likely be used conjointly. Indeed, their range of protection and detection are different.