Re: MIPS ASAN status? (and "volunteering")
2018-03-02 7:53 GMT+08:00 Hans-Peter Nilsson : > There's no address-sanitizer support for MIPS (in particular for > O32) on trunk, at least not when building for > mipsisa32r2el-linux-gnu and libsanitizer/configure.tgt seems > to support that observation. There's a set of patches "floating > around", but the last sign of work-in-progress was more than > four years ago, according to a well-known search engine. > > Is there something holding it up getting it into trunk gcc? > Is it just that someone needs to go the last mile? > > I can do that. I can even go two miles! Maybe even a merge > from compiler-rt and MIPS port hacking (to be merged post > gcc-8-branch to trunk, I presume). > > I'm a little worried that the "patches floating around" have > unclear copyright status, so I haven't looked at them yet. I'd > rather not re-do MIPS ASAN on the gcc-side from scratch, but if > it comes to that, so be it. > > brgds, H-P > It is great to go the last mile. I had done the port to mipsel-linux-uclibc gcc for GCC 4.9/5.0/6.0. Maybe I can give some help for you. Let's do the last mile. To do this, I have some questions. Should we port to the upstream LLVM first and port them back to GCC? Maybe some GCC-only files should be targeted directly like gcc/config/ and even configure.tgt. Regards, Jean
Re: MIPS ASAN status? (and "volunteering")
2018-03-03 21:14 GMT+08:00 Hans-Peter Nilsson : > > From: Jean Lee > > Date: Fri, 2 Mar 2018 13:29:39 +0800 > > > 2018-03-02 7:53 GMT+08:00 Hans-Peter Nilsson < > hans-peter.nils...@axis.com>: > > > > > There's no address-sanitizer support for MIPS (in particular for > > > O32) on trunk, at least not when building for > > > mipsisa32r2el-linux-gnu and libsanitizer/configure.tgt seems > > > to support that observation. There's a set of patches "floating > > > around", but the last sign of work-in-progress was more than > > > four years ago, according to a well-known search engine. > > > > > > Is there something holding it up getting it into trunk gcc? > > > Is it just that someone needs to go the last mile? > > > > > > I can do that. I can even go two miles! Maybe even a merge > > > from compiler-rt and MIPS port hacking (to be merged post > > > gcc-8-branch to trunk, I presume). > > > > > > I'm a little worried that the "patches floating around" have > > > unclear copyright status, so I haven't looked at them yet. I'd > > > rather not re-do MIPS ASAN on the gcc-side from scratch, but if > > > it comes to that, so be it. > > > > > > brgds, H-P > > > > > > > It is great to go the last mile. I had done the port to > > mipsel-linux-uclibc gcc for GCC 4.9/5.0/6.0. > > Maybe I can give some help for you. > > That would be great, thanks in advance! > > First a few troublesome questions: > > Are you the sole copyright owner of the patches to gcc that you > know of? (Not including compiler-rt patches, those are for the > compiler-rt people to worry about; I don't know their process.) > > If so, have you copyright assignment paper work in progress > done or in progress with the FSF for gcc? (From what I can > tell, if so, it's not completed.) If not, it'd be great if you > can get that started, it takes quite a while. > > I believe that's necessary for gcc-specific parts, but I don't > really decide that. But, if those patches are small enough to > not requiring paperwork they're probably also uninteresting > enough that I add them as I go by. > My port of MIPS uclibc libsanitizer of gcc-6.x is now put in github. https://github.com/xiaoyur347/sanitizer/ Much work was done to fix uclibc not MIPS. If you just need MIPS, maybe two patches are needed. 1. https://github.com/xiaoyur347/sanitizer/commit/016a8187c47f58de9b059eb77aa00e066aae309c for gcc/config 2. libsanitizer/configure.tgt + mipsel-*-linux*) ;; 3. Other works are for stack unwind, if the stack unwind doesn't call malloc() at all, it will be easy. > > Let's do the last mile. > > To do this, I have some questions. > > Should we port to the upstream LLVM first and port them back to GCC? > > I have no interest in LLVM at present, and can't wait, so: > no, not on my behalf. > > But the question makes me wonder: are you implying that ASAN > support for MIPS (O32 little-endian) isn't in upstream > Clang/LLVM *too* or do I misunderstand you? I'm not sure how to > tell myself (save for building it from scratch and trying it, > which I haven't done). > > *searches the web again...* > > It's not mentioned on > <http://clang.llvm.org/docs/AddressSanitizer.html>, but that > page seems out-of-date (known working platforms not mentioned). > It's mentioned on > <https://github.com/google/sanitizers/wiki/AddressSanitizer> so > maybe I concluded that since MIPS O32 support is not yet in GCC, > it must have been developed using LLVM. I thought I saw reviews > for 3+ year accepted patches, but looking closer that must have > been mips64 support. > > Thanks again for your support! > > brgds, H-P >
Re: MIPS ASAN status? (and "volunteering")
> See above regarding looking at patches, but I guess you mean > that the patch is trivial, so then I presume it was more or less > the same as this, which is basically a copy-paste from looking > at rs6000 and xtensa. I checked a typical /proc/self/maps and > guess that 1<<29 probably fits for MIPS o32 too: No, Not more or less the same as a copy-paste from rs6000. mips_asan_shadow_offset should use 0x0aaa as defined in libsanitizer/sanitizer_common/asan_mapping.h static const u64 kMIPS32_ShadowOffset32 = 0x0aaa; Maybe it is the main reason of your crash. >- FIRST_32_SECOND_64(160, 216); >+ FIRST_32_SECOND_64(144, 216); >If you (or anyone else) has a clue on the kernel-stat size >160 vs. 144 issue, or can point out "usual suspects" when always >getting SEGV with -fsanitize=address, I'm very interested. struct_kernel_stat_sz was once 144 for MIPS but it changes to 160 after this commit https://llvm.org/viewvc/llvm-project?view=revision&revision=301307 or https://github.com/llvm-mirror/compiler-rt/commit/e80e955171a57aa3be9a9d03404a7e9652b8a78d Maybe you should ask llvm for help. Regards.
gcc addresssanitizer in MIPS
My port of addresssanitizer is based on GCC 4.8.1.
I modify "asan_emit_stack_protection" function in gcc/asan.c for the
following reason:
Sometimes, the stack variable size > 32 Bytes, and after asan
generates code to poison the shadow buffer, it does clear some shadow
buffer but not all before function return.
So I use the way of poisoning to recover the shadow.
Does any of you suffer the problem? It works fine for my platform now.
about line 1050:
#if 0 // I find some false positive for those code
for (l = length; l; l -= 2)
{
offset = base_offset + ((offsets[l - 1] - base_offset)
& ~(ASAN_RED_ZONE_SIZE - HOST_WIDE_INT_1));
if (last_offset + last_size != offset)
{
shadow_mem = adjust_address (shadow_mem, VOIDmode,
(last_offset - prev_offset)
>> ASAN_SHADOW_SHIFT);
prev_offset = last_offset;
asan_clear_shadow (shadow_mem, last_size >> ASAN_SHADOW_SHIFT);
last_offset = offset;
last_size = 0;
}
last_size += base_offset + ((offsets[l - 2] - base_offset)
& ~(ASAN_RED_ZONE_SIZE - HOST_WIDE_INT_1))
- offset;
}
if (last_size)
{
shadow_mem = adjust_address (shadow_mem, VOIDmode,
(last_offset - prev_offset)
>> ASAN_SHADOW_SHIFT);
asan_clear_shadow (shadow_mem, last_size >> ASAN_SHADOW_SHIFT);
}
#else
for (l = length; l; l -= 2)
{
if (l == 2)
cur_shadow_byte = ASAN_STACK_MAGIC_RIGHT;
offset = offsets[l - 1];
if ((offset - base_offset) & (ASAN_RED_ZONE_SIZE - 1))
{
HOST_WIDE_INT aoff
= base_offset + ((offset - base_offset)
& ~(ASAN_RED_ZONE_SIZE - HOST_WIDE_INT_1));
shadow_mem = adjust_address (shadow_mem, VOIDmode,
(aoff - prev_offset)
>> ASAN_SHADOW_SHIFT);
prev_offset = aoff;
aoff += (1 << ASAN_SHADOW_SHIFT) << 2;
asan_clear_shadow (shadow_mem, 4);
offset = aoff;
}
while (offset <= offsets[l - 2] - ASAN_RED_ZONE_SIZE)
{
shadow_mem = adjust_address (shadow_mem, VOIDmode,
(offset - prev_offset)
>> ASAN_SHADOW_SHIFT);
prev_offset = offset;
asan_clear_shadow (shadow_mem, 4);
offset += ASAN_RED_ZONE_SIZE;
}
}
#endif
Re: gcc addresssanitizer in MIPS
Addresssanitizer was added to GCC since GCC 4.8, and you should
compile with the flag "-fsanitize=address". Moreover, the
addresssanitizer support for MIPS is not implemented in offical GCC.
Does someone use addresssanitizer in other platform (i386/x64/arm/ppc)
suffer this problem?
Thanks,
Jean Lee
2013/10/28 :
>
>> On Oct 28, 2013, at 1:36 AM, Jean Lee wrote:
>>
>> My port of addresssanitizer is based on GCC 4.8.1.
>> I modify "asan_emit_stack_protection" function in gcc/asan.c for the
>> following reason:
>> Sometimes, the stack variable size > 32 Bytes, and after asan
>> generates code to poison the shadow buffer, it does clear some shadow
>> buffer but not all before function return.
>> So I use the way of poisoning to recover the shadow.
>> Does any of you suffer the problem? It works fine for my platform now.
>
> I don't have this issue with either n32 or n64 on mips64 implementation that
> we did here internally (Cavium) based on GCC 4.7. Did you make sure that you
> make the frame grown down (is it up, I don't have access to the source right
> now)?
>
> Thanks,
> Andrew Pinski
>
>
>>
>> about line 1050:
>> #if 0 // I find some false positive for those code
>> for (l = length; l; l -= 2)
>>{
>> offset = base_offset + ((offsets[l - 1] - base_offset)
>> & ~(ASAN_RED_ZONE_SIZE - HOST_WIDE_INT_1));
>> if (last_offset + last_size != offset)
>> {
>> shadow_mem = adjust_address (shadow_mem, VOIDmode,
>> (last_offset - prev_offset)
>>>> ASAN_SHADOW_SHIFT);
>> prev_offset = last_offset;
>> asan_clear_shadow (shadow_mem, last_size >> ASAN_SHADOW_SHIFT);
>> last_offset = offset;
>> last_size = 0;
>> }
>> last_size += base_offset + ((offsets[l - 2] - base_offset)
>> & ~(ASAN_RED_ZONE_SIZE - HOST_WIDE_INT_1))
>> - offset;
>>}
>> if (last_size)
>>{
>> shadow_mem = adjust_address (shadow_mem, VOIDmode,
>> (last_offset - prev_offset)
>>>> ASAN_SHADOW_SHIFT);
>> asan_clear_shadow (shadow_mem, last_size >> ASAN_SHADOW_SHIFT);
>>}
>>
>> #else
>> for (l = length; l; l -= 2)
>> {
>>if (l == 2)
>> cur_shadow_byte = ASAN_STACK_MAGIC_RIGHT;
>>offset = offsets[l - 1];
>>if ((offset - base_offset) & (ASAN_RED_ZONE_SIZE - 1))
>>{
>> HOST_WIDE_INT aoff
>>= base_offset + ((offset - base_offset)
>> & ~(ASAN_RED_ZONE_SIZE - HOST_WIDE_INT_1));
>> shadow_mem = adjust_address (shadow_mem, VOIDmode,
>> (aoff - prev_offset)
>>>> ASAN_SHADOW_SHIFT);
>> prev_offset = aoff;
>> aoff += (1 << ASAN_SHADOW_SHIFT) << 2;
>>
>> asan_clear_shadow (shadow_mem, 4);
>> offset = aoff;
>>}
>>while (offset <= offsets[l - 2] - ASAN_RED_ZONE_SIZE)
>>{
>> shadow_mem = adjust_address (shadow_mem, VOIDmode,
>> (offset - prev_offset)
>>>> ASAN_SHADOW_SHIFT);
>> prev_offset = offset;
>>
>> asan_clear_shadow (shadow_mem, 4);
>> offset += ASAN_RED_ZONE_SIZE;
>>}
>> }
>> #endif
gcc-asan.diff
Description: Binary data
Re: gcc addresssanitizer in MIPS
Hi Yury, try to use the patch for asan.c to see if it solve your problem.
pinskia, thank you. I compiled asan with libssp which mean the stack grows down.
I disassembled the compiled code and debuged the bin time to time
before I thought it was a bug.early this month.
I tried GCC 4.8.1 and GCC 4.9 snapshot 20130930.
Moreover I never see this problem when I use GCC 4.8 i386.
My test was to use attached time.cpp for asan test. And I found the
shadow memory was not cleared for variable tim (shadow memory address
range 0x2ea1f783-0x2ea1f788) and a strange "f4" lived in it.
0x2ea1f730: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x2ea1f740: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x2ea1f750: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x2ea1f760: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 f1
0x2ea1f770: f1 f1 f1 04 f4 f4 f4 f2 f2 f2 f2 00 04 f4 f4 f2
=>0x2ea1f780: f2 f2 f2[00]00 00 f4 00 04 f4 f4 f3 f3 f3 f3 00
0x2ea1f790: 00 00 00 00 00 00 f1 f1 f1 f1 04 f4 f4 f4 f2 f2
0x2ea1f7a0: f2 f2 00 00 00 00 f2 f2 f2 f2 00 00 00 00 00 00
0x2ea1f7b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x2ea1f7c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x2ea1f7d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
2013/10/29 Yury Gribov :
>> Yes, we do see this error on ARM.
>
> Here is another instance of the same bug:
> http://permalink.gmane.org/gmane.comp.debugging.address-sanitizer/531
>
>
>> Full description and suggested patch are available at
>> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58543
>> I'm curious whether suggested patch is going to work for Andrew.
>
> -Y
>
>
>
#include
#include
#include
static int GetDataAndTimeString(char* pszTime,unsigned int nLen)
{
if ( NULL != pszTime )
{
time_t b_time;
struct tm tim;
b_time=time(NULL);
localtime_r(&b_time, &tim);
struct timeb timebuffer;
ftime( &timebuffer );
snprintf(pszTime,nLen,"%d/%02d/%02d %02d:%02d:%02d.%03d",
tim.tm_year+1900,tim.tm_mon+1,tim.tm_mday,
tim.tm_hour,tim.tm_min,tim.tm_sec,timebuffer.millitm);
return 0;
}
return -1;
}
int main()
{
char szDate[32] = {0};
GetDataAndTimeString(szDate,sizeof(szDate));
return 0;
}
Re: gcc addresssanitizer in MIPS
Thanks. I will try Jakub patch listed in http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58543. 2013/10/29 Yury Gribov : >> "copy_to_mode_reg (Pmode, XEXP (shadow_mem, 0))" would be more direct. >> But it looks good to me with that change FWIW. > > Thanks, Richard. Note that Jakub has proposed an optimized patch on > gcc-patches ML (in Re: [PATCH] Invalid unpoisoning of stack redzones on > ARM). > > -Y
Re: gcc addresssanitizer in MIPS
I have tried Jakub patch listed in http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58543. It works for my env. Thanks. 2013/10/29 Jean Lee : > Thanks. I will try Jakub patch listed in > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58543. > > 2013/10/29 Yury Gribov : >>> "copy_to_mode_reg (Pmode, XEXP (shadow_mem, 0))" would be more direct. >>> But it looks good to me with that change FWIW. >> >> Thanks, Richard. Note that Jakub has proposed an optimized patch on >> gcc-patches ML (in Re: [PATCH] Invalid unpoisoning of stack redzones on >> ARM). >> >> -Y
