<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
On 5/7/12 7:24 PM, Nuno Lopes wrote:
<blockquote
cite="mid:20120508012440.Horde.M_DoA5Ue0BVPqGfIHVMx9KA@beta.mail.sapo.pt"
type="cite">Hi,
<br>
<br>
Please find in attach a patch to change the objectsize intrinsic's
signature.
<br>
My proposal is to add a third parameter to control whether
objectsize is allowed to perform checks at run-time or not.
<br>
This parameter is an integer, and a higher value indicates that
you're willing to accept a potentially higher run-time performance
penalty, while 0 means no work at run-time (the current behavior).
<br>
<br>
The idea is to use this intrinsic, for example, for array bound
checking.
<br>
<br>
Nothing is changed yet in objectsize: this patch only changes the
signature of the intrinsic and implements an auto-upgrade.
<br>
<br>
Comments, ideas, etc..?
<br>
</blockquote>
<br>
Before I begin, I want to apologize for the lengthy reply. However,
I've been working on memory safety checks for a long time.<br>
:)<br>
<br>
My initial impression is that I don't think this is the right
approach. The objectsize instruction, in your design, lacks
information that is useful for optimizing run-time checks and making
them more stringent with link-time optimization.<br>
<br>
First, your design does not distinguish between checks on
loads/stores/atomics and checks on GEPs. The problem with that is
that some memory safety systems treat these checks differently.
Many systems (SoftBound and SAFECode being just two) will allow GEPs
to generate out-of-bounds pointers so long as they are not
deferenced. This means that a GEP check and a load/store check have
different behavior when they fail. This requires both different
implementations of the checks as well as different rules of when and
how they can be optimized.<br>
<br>
Second, load/store/atomic checks need the size of the memory access
as well as its starting pointer to make sure that the load/store
doesn't "fall off the end" of a memory object. Your objectsize
design does not provide that information.<br>
<br>
Third, your design does not specify whether a check is on a pointer
which is only manipulated by code internal to the program or whether
the pointer can be manipulated by or returned from external code. A
usable memory safety system needs to know the difference; memory
safety guarantees need to be relaxed for pointers handled by
external library code. Otherwise, the application may exhibit false
positives during execution.<br>
<br>
Additionally, whether a check is complete (because it checks a
pointer handled by only internal code) or is incomplete (because it
checks a pointer that can be manipulated by external code) needs to
be communicated at the LLVM IR level. This is because other LLVM
IR-level analyses and transforms can be used to change incomplete
checks to complete checks. Your design currently leaves that
problem to the code generator, making it more difficult for many
LLVM developers to write incomplete to complete check
transformations.<br>
<br>
In short, if you want to build a generic infrastructure for memory
safety run-time checks, I strongly recommend that you start with the
work we did on SAFECode; we've dealt with these issues, and we have
a solution that we believe can be reused for memory safety tools
other than our own and potentially by safe language implementations
as well. As an FYI, a GSoC project that uses our lessons from
SAFECode to make generic instrumentation passes for memory safety
has been accepted and will be led by Kostya from Google and
co-mentored by me (if I understand the arrangement correctly).<br>
<br>
For the GSoC project, I should probably write up a document on the
generic run-time checks and what they do. Would you find this
document useful?<br>
<br>
-- John T.<br>
<br>
<blockquote
cite="mid:20120508012440.Horde.M_DoA5Ue0BVPqGfIHVMx9KA@beta.mail.sapo.pt"
type="cite">Thanks,
<br>
Nuno
<br>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
llvm-commits mailing list
<a class="moz-txt-link-abbreviated" href="mailto:llvm-commits@cs.uiuc.edu">llvm-commits@cs.uiuc.edu</a>
<a class="moz-txt-link-freetext" href="http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits">http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits</a>
</pre>
</blockquote>
<br>
</body>
</html>