Bug 226294

Summary: Use timingsafe_bcmp() in WTF::constantTimeMemcmp() when available
Product: WebKit Reporter: Chris Dumez <cdumez>
Component: Web Template FrameworkAssignee: Chris Dumez <cdumez>
Status: RESOLVED FIXED    
Severity: Normal CC: achristensen, benjamin, cmarcelo, darin, ews-watchlist, ggaren, sam, webkit-bug-importer
Priority: P2 Keywords: InRadar
Version: WebKit Nightly Build   
Hardware: Unspecified   
OS: Unspecified   
Attachments:
Description Flags
Patch
none
Patch none

Chris Dumez
Reported 2021-05-26 14:26:50 PDT
Use timingsafe_bcmp() in WTF::constantTimeMemcmp() when available, instead of our own custom implementation.
Attachments
Patch (1.79 KB, patch)
2021-05-26 14:28 PDT, Chris Dumez
no flags
Patch (2.54 KB, patch)
2021-05-26 18:01 PDT, Chris Dumez
no flags
Chris Dumez
Comment 1 2021-05-26 14:28:28 PDT
Alex Christensen
Comment 2 2021-05-26 16:47:12 PDT
Comment on attachment 429795 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=429795&action=review > Source/WTF/wtf/CryptographicUtilities.cpp:36 > + return timingsafe_bcmp(voidA, voidB, length); Why not timingsafe_memcmp, or should we rename constantTimeMemcmp to constantTimeBCmp?
Chris Dumez
Comment 3 2021-05-26 16:50:25 PDT
(In reply to Alex Christensen from comment #2) > Comment on attachment 429795 [details] > Patch > > View in context: > https://bugs.webkit.org/attachment.cgi?id=429795&action=review > > > Source/WTF/wtf/CryptographicUtilities.cpp:36 > > + return timingsafe_bcmp(voidA, voidB, length); > > Why not timingsafe_memcmp, or should we rename constantTimeMemcmp to > constantTimeBCmp? I didn't choose how the system API is called :) No, I cannot rename the system API to timingsafe_memcmp. We could rename the WTF:: constantTimeMemcmp to match BSD's naming but I personally prefer the memcmp naming.
Alex Christensen
Comment 4 2021-05-26 17:02:57 PDT
Comment on attachment 429795 [details] Patch Oh, I was looking at the bsd documentation, which has both. memcmp implies a directional return value that can be used in sorting, but this doesn't have that property. Our use only checks whether it's zero, though, so it's fine so far.
Alexey Proskuryakov
Comment 5 2021-05-26 17:26:59 PDT
Comment on attachment 429795 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=429795&action=review > Source/WTF/wtf/CryptographicUtilities.cpp:33 > NEVER_INLINE int constantTimeMemcmp(const void* voidA, const void* voidB, size_t length) This wrapper that's in a different dylib and forces no inlining is slightly wasteful when calling the system API. Perhaps implement the system API path in the header?
EWS
Comment 6 2021-05-26 17:39:13 PDT
Committed r278140 (238185@main): <https://commits.webkit.org/238185@main> All reviewed patches have been landed. Closing bug and clearing flags on attachment 429795 [details].
Radar WebKit Bug Importer
Comment 7 2021-05-26 17:40:17 PDT
Chris Dumez
Comment 8 2021-05-26 17:56:06 PDT
(In reply to Alexey Proskuryakov from comment #5) > Comment on attachment 429795 [details] > Patch > > View in context: > https://bugs.webkit.org/attachment.cgi?id=429795&action=review > > > Source/WTF/wtf/CryptographicUtilities.cpp:33 > > NEVER_INLINE int constantTimeMemcmp(const void* voidA, const void* voidB, size_t length) > > This wrapper that's in a different dylib and forces no inlining is slightly > wasteful when calling the system API. Perhaps implement the system API path > in the header? Sure, I can do that. I actually had hesitated to do that. I'll follow-up.
Chris Dumez
Comment 9 2021-05-26 18:01:44 PDT
Reopening to attach new patch.
Chris Dumez
Comment 10 2021-05-26 18:01:45 PDT
EWS
Comment 11 2021-05-26 18:49:02 PDT
Committed r278144 (238188@main): <https://commits.webkit.org/238188@main> All reviewed patches have been landed. Closing bug and clearing flags on attachment 429821 [details].
Sam Weinig
Comment 12 2021-05-28 17:50:13 PDT
This should probably use a new HAVE macro.
Chris Dumez
Comment 13 2021-05-28 17:51:15 PDT
(In reply to Sam Weinig from comment #12) > This should probably use a new HAVE macro. It's there, don't you see it? http://trac.webkit.org/r278178 :D
Sam Weinig
Comment 14 2021-05-30 09:57:07 PDT
(In reply to Chris Dumez from comment #13) > (In reply to Sam Weinig from comment #12) > > This should probably use a new HAVE macro. > > It's there, don't you see it? http://trac.webkit.org/r278178 :D Great!
Note You need to log in before you can comment on or make changes to this bug.