lkml.org 
[lkml]   [2019]   [Feb]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRe: [PATCH] kasan: turn off asan-stack for clang-8 and earlier
On Wed, Feb 20, 2019 at 2:12 PM Kostya Serebryany <kcc@google.com> wrote:
>
> On Wed, Feb 20, 2019 at 1:40 PM Arnd Bergmann <arnd@arndb.de> wrote:
> >
> > On Wed, Feb 20, 2019 at 10:13 PM Arnd Bergmann <arnd@arndb.de> wrote:
> > >
> > > In the example in https://bugs.llvm.org/show_bug.cgi?id=38809#c12
> > > (https://godbolt.org/z/ylsGSQ) there is no inlining, yet clang uses
> > > over ten times as much stack space as gcc, for reasons I still
> > > can't explain. My assumption right now is that the underlying bug
> > > causes most of the problems with excessive stack usage in
> > > allmodconfig kernels.
> >
> > Here is an even more minimal example:
> >
> > struct s { int i[5]; } f(void);
> > void g(void) { f(); f();}
>
> On this example I can see some stupidity that clang/asan is doing.
> Let me try fixing it and see if it helps bigger cases.
> Thanks for reducing the case!
>
> This is the input we get in the asan instrumentation:
>
> ; Function Attrs: noinline nounwind optnone sanitize_address uwtable
> define dso_local void @g() #0 {
> entry:
> %tmp = alloca %struct.s, align 4 <<<<<<<<<<<<<<<<<<<<<<<
> %tmp1 = alloca %struct.s, align 4
> %0 = bitcast %struct.s* %tmp to i8*
> call void @llvm.lifetime.start.p0i8(i64 20, i8* %0) #3
> call void @f(%struct.s* sret %tmp)
> %1 = bitcast %struct.s* %tmp to i8* <<<<<<<<<<<<<<<<<<<<<
> call void @llvm.lifetime.end.p0i8(i64 20, i8* %1) #3
> %2 = bitcast %struct.s* %tmp1 to i8*
> call void @llvm.lifetime.start.p0i8(i64 20, i8* %2) #3 <<<<<<<<<<<<<
> call void @f(%struct.s* sret %tmp1)
> %3 = bitcast %struct.s* %tmp1 to i8*
> call void @llvm.lifetime.end.p0i8(i64 20, i8* %3) #3
> ret void
> }

Err.. taking my words back.
These allocas *are* used other then in lifetime markers, since they
are passed to f() as 'sret'.
And we can not drop instrumentation for such allocas. Example:

static volatile int zero = 0;
typedef struct {
int ar[5];
} S;
S foo() {
S s;
s.ar[zero + 6] = 42;
return s;
}
int main(int argc, char **argv) {
S s = foo();
return s.ar[argc];
}

% clang -g -O1 -fsanitize=address sret.c && ./a.out

==5822==ERROR: AddressSanitizer: stack-buffer-overflow on address
0x7ffcad027f78 at pc 0x0000004f878d bp 0x7ffcad027f20 sp
0x7ffcad027f18
WRITE of size 4 at 0x7ffcad027f78 thread T0
#0 0x4f878c in foo sret.c:7:18
#1 0x4f8838 in main sret.c:11:9
Address 0x7ffcad027f78 is located in stack of thread T0 at offset 56 in frame
#0 0x4f879f in main sret.c:10

This frame has 1 object(s):
[32, 52) 's' (line 11) <== Memory access at offset 56 overflows
this variable

Here we have a struct return that needs to be instrumented inside main
so that a buffer overflow in foo() is detected.

Now, I am also not confident that the reduced case reflects the real problem.

--kcc









>
> the stack variables are not *really* used, but since they are "used"
> inside the lifetime markers they are not eliminated by asan,
> and so asan instruments them, after which no one can remove them any more...
>
>
>
>
> >
> > https://godbolt.org/z/d_KWkh
> >
> > It's clear that clang does /something/ here when asan-stack=1 is
> > set, but I fail to see what it is, or why that is necessary.
> >
> > The output of clang with asan-stack=0 is the expected
> > code, and basically identical to what gcc produces with or
> > without asan-stack.
> >
> > Arnd

\
 
 \ /
  Last update: 2019-02-21 00:49    [W:0.980 / U:0.084 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site