[SERVER-43876] Look into using ASAN annotations to improve reliability Created: 07/Oct/19  Updated: 06/Dec/22

Status: Open
Project: Core Server
Component/s: Internal Code
Affects Version/s: None
Fix Version/s: None

Type: Task Priority: Major - P3
Reporter: Mathias Stearn Assignee: Backlog - Service Architecture
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Assigned Teams:
Service Arch
Participants:

 Description   

Look into using ASAN annotations like __asan_poison_memory_region and __asan_unpoison_memory_region to mark areas of memory that should not be touched, even if they are still allocated. Alternatively, consider not reusing buffers and always allocating new ones in ASAN-enabled builds.



 Comments   
Comment by Mathias Stearn [ 13/Sep/22 ]

Unfortunately I don't recall the details of the conversation that spawned this ticket anymore.

 

One case that I think could be useful is that we often over-allocate buffers, eg when doing power-of-2 growth, but only a portion of the allocated memory should be in use. We could have BufBuilder start with all newly allocated memory poisoned, and then unpoison it as it is appended to.

Comment by Andy Schwerin [ 25/Aug/22 ]

The idea is that sometimes our source code knows that a region of memory has become illegal to access, but we haven't returned it to the allocator by calling free(), yet. In these cases, you can (or at least once could) [manually poison the memory, telling ASAN that further accesses of the memory were asan violations until such time as our code chose to unpoison the memory region.

I believe we thought this would be interesting because we have buffers that we re-use without {{free()}}ing, and right now ASAN cannot detect illegal accesses to those buffers in between legitimate uses of them.

mathias@mongodb.com, can you give a couple examples of such buffers? I think maybe there are some in the networking stack, but I'm not sure where else.

Comment by Lauren Lewis (Inactive) [ 21/Dec/21 ]

We haven’t heard back from you in at least 1 year, so I'm going to close this ticket. If this is still an issue for you, please provide additional information and we will reopen the ticket.

Generated at Thu Feb 08 05:04:21 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.