<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/xhtml; charset=utf-8">
</head>
<body>
<div style="font-family:sans-serif"><div style="white-space:normal">
<p dir="auto">On 6 May 2020, at 18:40, JF Bastien wrote:</p>
</div>
<div style="white-space:normal"><blockquote style="border-left:2px solid #777; color:#777; margin:0 0 5px; padding-left:5px"><p dir="auto">Hi fans of volatility!<br>
<br>
I’d like to add volatile overloads to mem* builtins, and authored a patch: <a href="https://reviews.llvm.org/D79279" style="color:#777">https://reviews.llvm.org/D79279</a> <<a href="https://reviews.llvm.org/D79279" style="color:#777">https://reviews.llvm.org/D79279</a>><br>
<br>
The mem* builtins are often used (or should be used) in places where time-of-check 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. The current builtins don't accept volatile pointee parameters in C++, and merely warn about such parameters in C, which leads to confusion. In these settings, it's useful to overload the builtin and permit volatile pointee parameters. The code generation then directly emits the existing volatile variant of the mem* builtin function call, which ensures that the affected memory location is only accessed once (thereby preventing double-reads under an adversarial memory mapping).<br>
<br>
Side-note: yes, ToCToU avoidance is a valid use for volatile <<a href="https://wg21.link/p1152r0#uses" style="color:#777">https://wg21.link/p1152r0#uses</a>>.<br>
<br>
My patch currently only affects:<br>
__builtin_memcpy<br>
__builtin_memmove<br>
__builtin_memset<br>
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.<br>
<br>
John brought up the following: __builtin_memcpy is a library builtin, which means its primary use pattern is #define tricks in the C standard library headers that redirect calls to the memcpy library function. So doing what you're suggesting to __builtin_memcpy is also changing the semantics of memcpy, 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.<br>
<br>
I can instead add __builtin_volatile_* functions which are overloaded on at least one pointee parameter being volatile.</p>
</blockquote></div>
<div style="white-space:normal">
<p dir="auto">So, to be clear, you would like there to be some way to request a volatile <code style="background-color:#F7F7F7; border-radius:3px; margin:0; padding:0 0.4em" bgcolor="#F7F7F7">memcpy</code> (etc.). You don’t need it to specifically be <code style="background-color:#F7F7F7; border-radius:3px; margin:0; padding:0 0.4em" bgcolor="#F7F7F7">__builtin_memcpy</code> (etc.) — i.e. you’re not relying on this automatically triggering when users call <code style="background-color:#F7F7F7; border-radius:3px; margin:0; padding:0 0.4em" bgcolor="#F7F7F7">memcpy</code> — you just need some way to spell it.</p>
<p dir="auto">A few thoughts:</p>
<ul>
<li><p dir="auto">A <code style="background-color:#F7F7F7; border-radius:3px; margin:0; padding:0 0.4em" bgcolor="#F7F7F7">memcpy</code>/<code style="background-color:#F7F7F7; border-radius:3px; margin:0; padding:0 0.4em" bgcolor="#F7F7F7">memmove</code> is conceptually a load from one address and a store to another. It is potentially valuable to know that e.g. only the store is <code style="background-color:#F7F7F7; border-radius:3px; margin:0; padding:0 0.4em" bgcolor="#F7F7F7">volatile</code>. We can’t express that in today’s LLVM intrinsics, but it’s certainly imaginable that we could express it in the future, the same way that we added the ability to record different alignments for both sides. So I think it would be nice if whatever we do here allows us to pick up on the difference, e.g. by triggering based on the qualification of the source/dest pointers.</p></li>
<li><p dir="auto">There are other qualifiers that can meaningfully contribute to the operation here besides <code style="background-color:#F7F7F7; border-radius:3px; margin:0; padding:0 0.4em" bgcolor="#F7F7F7">volatile</code>, such as <code style="background-color:#F7F7F7; border-radius:3px; margin:0; padding:0 0.4em" bgcolor="#F7F7F7">restrict</code> and (more importantly) address spaces. And again, for the copy operations these might differ between the two pointer types.</p></li>
</ul>
<p dir="auto">In both cases, I’d say that the logical design is to allow the pointers to be to arbitrarily-qualified types. We can then propagate that information from the builtin into the LLVM intrinsic call as best as we’re allowed. So I think you should make builtins called something like <code style="background-color:#F7F7F7; border-radius:3px; margin:0; padding:0 0.4em" bgcolor="#F7F7F7">__builtin_overloaded_memcpy</code> (name to be decided) and just have their semantics be type-directed.</p>
<p dir="auto">I do think it would treacherous to actually apply these semantics to <code style="background-color:#F7F7F7; border-radius:3px; margin:0; padding:0 0.4em" bgcolor="#F7F7F7">memcpy</code> via <code style="background-color:#F7F7F7; border-radius:3px; margin:0; padding:0 0.4em" bgcolor="#F7F7F7">__builtin_memcpy</code>, though.</p>
<p dir="auto">John.</p>
</div>
</div>
</body>
</html>