Improve safety of MachMessage class

[Chris Dumez]

Improve safety of MachMessage class and clean things up a bit.

[Chris Dumez]

<rdar://problem/44291920>

[Chris Dumez]

Created attachment 368346 [details]
Patch

[Chris Dumez]

Created attachment 368353 [details]
Patch

[Alex Christensen]

Comment on attachment 368353 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=368353&action=review

> Source/WebKit/Platform/IPC/mac/MachMessage.cpp:37
> +    void* memory = WTF::fastZeroedMalloc(sizeof(MachMessage) + size);

Are there any performance indications of this change?

[Chris Dumez]

(In reply to Alex Christensen from comment #4)
> Comment on attachment 368353 [details]
> Patch
> 
> View in context:
> https://bugs.webkit.org/attachment.cgi?id=368353&action=review
> 
> > Source/WebKit/Platform/IPC/mac/MachMessage.cpp:37
> > +    void* memory = WTF::fastZeroedMalloc(sizeof(MachMessage) + size);
> 
> Are there any performance indications of this change?

There could be a performance impact although I personally doubt it. I believe zero'ing memory is normally pretty cheap and while IPC is frequent, I do not believe it is super-hot.

Any any case, this is security-sensitive code so we want it to be robust. I have also explain in the changelog and in the radar (in more details) why I believe this will fix flaky crashes.

If it does regress performance, then we can try and find another solution but I think other solution will likely be more fragile. I say let's try the safest / most robust thing first.

[WebKit Commit Bot]

Comment on attachment 368353 [details]
Patch

Clearing flags on attachment: 368353

Committed r244721: <https://trac.webkit.org/changeset/244721>

[WebKit Commit Bot]

All reviewed patches have been landed.  Closing bug.