GWP-ASan guarded allocation size limitation

[zlobober]

Hi!

From what I see in the implementation and in the documentation, allocations consisting of more than a single page are not sampled, and therefore are not subject to address sanitizing.

Such limitation contradicts my intuition. Aren't smaller allocations the ones that introduce relatively larger amount of CPU & RAM overhead for guarding? Why is allocation of, let's say, 1 MiB expensive? Doesn't it require only two extra fence pages?

[danlark1]

Generally the idea came from the fact that around 50% of all allocations were <8kb in top of our workloads and at the same time to make things easier to interleave Guarded/Allocated pages to make the structure static. This way we can easy detect where the address has laid to when reporting without storing additional data. guarded_page_allocator.cc uses quite a lot of that idea. That does not stop us from implementing bigger allocations, for sure, that has been on the roadmap and went into a backlog even though we had cases when we needed it

[zlobober]

Hi, Daniel :)

Well, in our application (data-intensive workloads, lots of asynchronous code) there were lots of cases with ownership issues/buffer overflows for allocations containing data blobs. Sometimes such blobs come directly from the disk, and may be of size up to ~16 MiB. So it would be helpful to implement similar approach for larger allocations.

If you need arguments for moving this feature out of a backlog, count us in.