<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="">I indeed think that this is fine for the purpose I’ve stated.<div class=""><br class=""></div><div class="">Fundamentally, if you’re interacting with device memory you want to know that accesses are performed in a certain order, at a certain size granularity. Today’s C and C++ implementations volatile on scalars effectively provide this knowledge, even if the Standard doesn’t say so. Volatile on anything “large” (more than one or two registers) doesn’t, and ought not to be used for device memory with specific semantics.</div><div class=""><br class=""></div><div class="">However, the volatile usage for ToCToU doesn’t care if what you describe happens! An adversary can race all they want, as long as any validity check occurs after the copy has completed then we’re fine.</div><div class=""><br class=""></div><div class="">Maybe this argues for calling the builtin something else than volatile, but still mapping it to volatile memcpy IR for now?</div><div class=""><br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On May 7, 2020, at 3:07 PM, James Y Knight via cfe-dev <<a href="mailto:cfe-dev@lists.llvm.org" class="">cfe-dev@lists.llvm.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class=""><div class=""></div><div class="">Volatile memcpy/memset/etc are indeed rather underspecified. As LangRef states, "If the isvolatile parameter is true, the llvm.memcpy call is a volatile operation. The detailed access behavior is not very cleanly specified and it is unwise to depend on it."</div><div class=""><div class=""><br class=""></div><div class="">I think the intent at the moment is that the mem-operation as a whole should be treated as volatile -- so the memory copy, as a whole, will happen only once -- but that there's no guarantee as to what loads/stores are used to implement that, including potentially reading/writing some bytes multiple times, with different access sizes. I think those semantics make sense, but really ought to be fully nailed down.</div></div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""></div></div><br class=""><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, May 7, 2020 at 5:13 PM Joerg Sonnenberger via cfe-dev <<a href="mailto:cfe-dev@lists.llvm.org" class="">cfe-dev@lists.llvm.org</a>> wrote:<br class=""></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Wed, May 06, 2020 at 03:40:43PM -0700, JF Bastien via cfe-dev wrote:<br class="">
> I’d like to add volatile overloads to mem* builtins, and authored a patch: <a href="https://reviews.llvm.org/D79279" rel="noreferrer" target="_blank" class="">https://reviews.llvm.org/D79279</a> <<a href="https://reviews.llvm.org/D79279" rel="noreferrer" target="_blank" class="">https://reviews.llvm.org/D79279</a>><br class="">
<br class="">
The major issue I have here is that it seems to seriously underspecify<br class="">
what it is actually happening with the memory. Consider an<br class="">
implementation of memset for example. It is entirely legal and<br class="">
potentially even useful to check for length being >= two registers and<br class="">
in that case implement it as<br class="">
write to [start, start+reglen)<br class="">
write to [start+len-reglen,start+len)<br class="">
write to (start+reglen)&(reglen-1) in reglen blocks until reaching<br class="">
the end<br class="">
<br class="">
or variations to try to hide the unaligned head and tail case in the<br class="">
main loop. This would violate the normal assumptions around volatile,<br class="">
e.g. when using device memory.<br class="">
<br class="">
Joerg<br class="">
_______________________________________________<br class="">
cfe-dev mailing list<br class="">
<a href="mailto:cfe-dev@lists.llvm.org" target="_blank" class="">cfe-dev@lists.llvm.org</a><br class="">
<a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev" rel="noreferrer" target="_blank" class="">https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev</a><br class="">
</blockquote></div>
_______________________________________________<br class="">cfe-dev mailing list<br class=""><a href="mailto:cfe-dev@lists.llvm.org" class="">cfe-dev@lists.llvm.org</a><br class="">https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev<br class=""></div></blockquote></div><br class=""></div></body></html>