llvm dev - Mar 2013 - [LLVMdev] (Not) instrumenting global string literals that end up in .cstrings on Mac

(forgot to CC llvmdev)

On Thu, Mar 21, 2013 at 5:54 PM, Alexander Potapenko <glider at
google.com> wrote:
> Hey Anna, Nick, Ted,
>
> We've the following problem with string literals under ASan on Mac.
> Some global string constants end up being put into the .cstring
> section, for which the following rules apply:
>  - the strings can't contain zeroes in their bodies
>  - the link editor places only one copy of each literal into the
> output file's section
>
> ASan usually instruments the globals by adding redzones to the end of
> them and creating a structure that contains the size of a global with
> and without the redzone.
> For the aforementioned strings the linker will delete the redzones,
> but leave that structure untouched, which will lead to corrupt shadow
> memory at run time.
>
> Unfortunately at instrumentation time we can't tell for sure whether
> the string constant will be put into the .cstring section or not - the
> decision is taken at lowering time.
> https://code.google.com/p/address-sanitizer/issues/detail?id=171
> contains the writeup of the problem and a couple of suggestions on how
> it can be solved. But we aren't sure that any of the solutions is
> correct.
> I wonder if it's at all possible to understand that a given string
> constant is going to end up in a mergeable section. Otherwise, is it
> possible to make every string literal live in a non-mergeable section
> by setting the section name explicitly?
>
> TIA,
> Alex

Alexander,

On Darwin the "__cstring" section (really section with type
S_CSTRING_LITERAL) is defined to contain zero terminate strings of bytes that
the linker can merge and re-order.  If you want pad bytes before and after the
string, you need to put the strings in a different section (e.g. __TEXT,
__const).

But, CF/NSString literals will be problematic.  The compiler emits a static
NS/CFString object into a data section.  That object contains a pointer to its
"backing" utf8 or utf16 string literal.  The linker coalesce the
NS/CFString objects (so that two translation units that define
@"hello" will wind up using the same object).  But to tell if two
CF/NSString objects are the same, the linker must compare the string literal
they point to.  And in that check is an assertion that the string is in a
__cstring or __ustring (utf16) section.  So, putting the backing string for a
CF/NSString into another section will cause a linker assertion.

-Nick


On Mar 21, 2013, at 7:05 AM, Alexander Potapenko <glider at google.com>
wrote:
> (forgot to CC llvmdev)
> 
> On Thu, Mar 21, 2013 at 5:54 PM, Alexander Potapenko <glider at
google.com> wrote:
>> Hey Anna, Nick, Ted,
>> 
>> We've the following problem with string literals under ASan on Mac.
>> Some global string constants end up being put into the .cstring
>> section, for which the following rules apply:
>> - the strings can't contain zeroes in their bodies
>> - the link editor places only one copy of each literal into the
>> output file's section
>> 
>> ASan usually instruments the globals by adding redzones to the end of
>> them and creating a structure that contains the size of a global with
>> and without the redzone.
>> For the aforementioned strings the linker will delete the redzones,
>> but leave that structure untouched, which will lead to corrupt shadow
>> memory at run time.
>> 
>> Unfortunately at instrumentation time we can't tell for sure
whether
>> the string constant will be put into the .cstring section or not - the
>> decision is taken at lowering time.
>> https://code.google.com/p/address-sanitizer/issues/detail?id=171
>> contains the writeup of the problem and a couple of suggestions on how
>> it can be solved. But we aren't sure that any of the solutions is
>> correct.
>> I wonder if it's at all possible to understand that a given string
>> constant is going to end up in a mergeable section. Otherwise, is it
>> possible to make every string literal live in a non-mergeable section
>> by setting the section name explicitly?
>> 
>> TIA,
>> Alex

Alex,

I think finding a superset of globals that will end up in the
"__cstring" section and not adding red zones to them is reasonable.
You might be able to factor out the code that makes the decision but does not
involve TargetMachine (ex: some of TargetLoweringObjectFile::getKindForGlobal).
These are all constants anyway, so we are only loosing checks for invalid reads,
not invalid writes.

There might be other, better solutions; I am not sure..

Cheers,
Anna.


On Mar 21, 2013, at 12:03 PM, Nick Kledzik <kledzik at apple.com> wrote:
> Alexander,
> 
> On Darwin the "__cstring" section (really section with type
S_CSTRING_LITERAL) is defined to contain zero terminate strings of bytes that
the linker can merge and re-order.  If you want pad bytes before and after the
string, you need to put the strings in a different section (e.g. __TEXT,
__const).
> 
> But, CF/NSString literals will be problematic.  The compiler emits a static
NS/CFString object into a data section.  That object contains a pointer to its
"backing" utf8 or utf16 string literal.  The linker coalesce the
NS/CFString objects (so that two translation units that define
@"hello" will wind up using the same object).  But to tell if two
CF/NSString objects are the same, the linker must compare the string literal
they point to.  And in that check is an assertion that the string is in a
__cstring or __ustring (utf16) section.  So, putting the backing string for a
CF/NSString into another section will cause a linker assertion.
> 
> -Nick
> 
> 
> On Mar 21, 2013, at 7:05 AM, Alexander Potapenko <glider at
google.com> wrote:
>> (forgot to CC llvmdev)
>> 
>> On Thu, Mar 21, 2013 at 5:54 PM, Alexander Potapenko <glider at
google.com> wrote:
>>> Hey Anna, Nick, Ted,
>>> 
>>> We've the following problem with string literals under ASan on
Mac.
>>> Some global string constants end up being put into the .cstring
>>> section, for which the following rules apply:
>>> - the strings can't contain zeroes in their bodies
>>> - the link editor places only one copy of each literal into the
>>> output file's section
>>> 
>>> ASan usually instruments the globals by adding redzones to the end
of
>>> them and creating a structure that contains the size of a global
with
>>> and without the redzone.
>>> For the aforementioned strings the linker will delete the redzones,
>>> but leave that structure untouched, which will lead to corrupt
shadow
>>> memory at run time.
>>> 
>>> Unfortunately at instrumentation time we can't tell for sure
whether
>>> the string constant will be put into the .cstring section or not -
the
>>> decision is taken at lowering time.
>>> https://code.google.com/p/address-sanitizer/issues/detail?id=171
>>> contains the writeup of the problem and a couple of suggestions on
how
>>> it can be solved. But we aren't sure that any of the solutions
is
>>> correct.
>>> I wonder if it's at all possible to understand that a given
string
>>> constant is going to end up in a mergeable section. Otherwise, is
it
>>> possible to make every string literal live in a non-mergeable
section
>>> by setting the section name explicitly?
>>> 
>>> TIA,
>>> Alex
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20130321/e318b67e/attachment.html>