<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">Hi fans of volatility!<div class=""><br class=""></div><div class="">I’d like to add volatile overloads to <font face="Courier" class="">mem*</font> builtins, and authored a patch: <a href="https://reviews.llvm.org/D79279" class="">https://reviews.llvm.org/D79279</a></div><div class=""><br class=""></div><div class=""><span style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);" class="">The <font face="Courier" class="">mem*</font> builtins are often used (or should be used) in places where time-of-check </span><font color="#000000" class=""><span style="caret-color: rgb(0, 0, 0);" class="">time-of-use security issues are important (e.g. copying from untrusted buffers), because it prevents multiple reads / multiple writes from occurring at the untrusted memory location. </span></font><span style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);" class="">The current builtins don't accept volatile pointee parameters in C++, and merely warn about such </span><span style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);" class="">parameters in C, which leads to confusion. In these settings, it's useful to </span><span style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);" class="">overload the builtin and permit volatile pointee parameters. The code generation </span><span style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);" class="">then directly emits the existing volatile variant of the <font face="Courier" class="">mem*</font> builtin function </span><span style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);" class="">call, which ensures that the affected memory location is only accessed once </span><font color="#000000" class=""><span style="caret-color: rgb(0, 0, 0);" class="">(thereby preventing double-reads under an adversarial memory mapping).</span></font></div><div class=""><font color="#000000" class=""><span style="caret-color: rgb(0, 0, 0);" class=""><br class=""></span></font></div><div class=""><font color="#000000" class=""><span style="caret-color: rgb(0, 0, 0);" class="">Side-note: yes, ToCToU avoidance </span></font><a href="https://wg21.link/p1152r0#uses" class="">is a valid use for volatile</a><font color="#000000" class=""><span style="caret-color: rgb(0, 0, 0);" class="">.</span></font></div><div class=""><span style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);" class=""><br class=""></span></div><div class=""><span style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);" class="">My patch currently only affects:</span></div><div class=""><ul class=""><li class=""><span style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);" class=""><font face="Courier" class="">__builtin_memcpy</font></span></li><li class=""><span style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);" class=""><font face="Courier" class="">__builtin_memmove</font></span></li><li class=""><span style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);" class=""><font face="Courier" class="">__builtin_memset</font></span></li></ul></div><div class=""><font color="#000000" class="">There’s a bunch more “mem-like” functions such as bzero, but those 3 are the ones I expect to be used the most at the moment. We can add others later.</font></div><div class=""><font color="#000000" class=""><br class=""></font></div><div class=""><font color="#000000" class="">John brought up the following: <span style="caret-color: rgb(0, 0, 0);" class=""><font face="Courier" class="">__builtin_memcpy</font> is a library builtin, which means its primary use pattern is <font face="Courier" class="">#define</font> tricks in the C standard library headers that redirect calls to the <font face="Courier" class="">memcpy</font> library function. So doing what you're suggesting to <font face="Courier" class="">__builtin_memcpy</font> is also changing the semantics of <font face="Courier" class="">memcpy</font>, which is not something we should do lightly. If we were talking about changing a non-library builtin function, or introducing a new builtin, the considerations would be very different.</span></font></div><div class=""><font color="#000000" class=""><span style="caret-color: rgb(0, 0, 0);" class=""><br class=""></span></font></div><div class=""><font color="#000000" class="">I can instead add <font face="Courier" class="">__builtin_volatile_*</font> functions which are overloaded on at least one pointee parameter being volatile.</font></div><div class=""><font color="#000000" class=""><br class=""></font></div><div class=""><font color="#000000" class="">What do y’all think?</font></div><div class=""><font color="#000000" class=""><br class=""></font></div><div class=""><font color="#000000" class="">Thanks,</font></div><div class=""><font color="#000000" class=""><br class=""></font></div><div class=""><font color="#000000" class="">JF</font></div></body></html>