https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81715
--- Comment #25 from Martin Liška <marxin at gcc dot gnu.org> ---
(In reply to Arnd Bergmann from comment #24)
> (In reply to Martin Liška from comment #23)
>
> > That's definitely possible for GCC 9. Question is whether such change will
> > be sufficient for you. Do you expect it will reduce stack usage in the
> > desired way?
>
> I've recreated my original finding, comparing a clang-5 release against a
> recent gcc-8 snapshot. Building an x86 allmodconfig kernel with clang, I get
> 78 -fsanitize-address-use-after-scope warnings against a 2048 byte limit,
> the largest ones are:
>
> drivers/usb/misc/sisusbvga/sisusb.c:1880:12: warning: stack frame size of
> 6776 bytes in function 'sisusb_init_gfxcore' [-Wframe-larger-than=]
> drivers/gpu/drm/nouveau/nvkm/subdev/fb/ramgk104.c:1521:1: warning: stack
> frame size of 5176 bytes in function 'gk104_ram_new_' [-Wframe-larger-than=]
> drivers/usb/misc/sisusbvga/sisusb.c:1750:12: warning: stack frame size of
> 5112 bytes in function 'sisusb_set_default_mode' [-Wframe-larger-than=]
> drivers/net/wireless/atmel/atmel.c:1307:5: warning: stack frame size of 5016
> bytes in function 'atmel_open' [-Wframe-larger-than=]
> net/core/ethtool.c:2549:5: warning: stack frame size of 4568 bytes in
> function 'dev_ethtool' [-Wframe-larger-than=]
> drivers/net/wireless/broadcom/brcm80211/brcmsmac/phy/phy_n.c:19216:6:
> warning: stack frame size of 4312 bytes in function 'wlc_phy_init_nphy'
> [-Wframe-larger-than=]
> drivers/media/usb/em28xx/em28xx-dvb.c:1129:12: warning: stack frame size of
> 3992 bytes in function 'em28xx_dvb_init' [-Wframe-larger-than=]
> drivers/staging/media/atomisp/pci/atomisp2/css2400/sh_css.c:6802:24:
> warning: stack frame size of 3960 bytes in function 'load_capture_binaries'
> [-Wframe-larger-than=]
> drivers/staging/wlan-ng/cfg80211.c:454:12: warning: stack frame size of 3864
> bytes in function 'prism2_connect' [-Wframe-larger-than=]
> drivers/staging/wilc1000/host_interface.c:2480:13: warning: stack frame size
> of 3704 bytes in function 'host_if_work' [-Wframe-larger-than=]
>
>
> With gcc-8, the same configuration has 179 warnings, including:
>
> drivers/net/wireless/ralink/rt2x00/rt2800lib.c:5650:1: warning: the frame
> size of 23632 bytes is larger than 2048 bytes [-Wframe-larger-than=]
> drivers/net/wireless/ralink/rt2x00/rt2800lib.c:4515:1: warning: the frame
> size of 14056 bytes is larger than 2048 bytes [-Wframe-larger-than=]
> drivers/net/wireless/ralink/rt2x00/rt2800lib.c:3879:1: warning: the frame
> size of 11504 bytes is larger than 2048 bytes [-Wframe-larger-than=]
> lib/atomic64_test.c:250:1: warning: the frame size of 11192 bytes is larger
> than 2048 bytes [-Wframe-larger-than=]
> lib/atomic64_test.c:148:1: warning: the frame size of 10360 bytes is larger
> than 2048 bytes [-Wframe-larger-than=]
> drivers/net/wireless/ralink/rt2x00/rt73usb.c:1294:1: warning: the frame size
> of 8680 bytes is larger than 2048 bytes [-Wframe-larger-than=]
> fs/fscache/stats.c:287:1: warning: the frame size of 6536 bytes is larger
> than 2048 bytes [-Wframe-larger-than=]
> drivers/net/wireless/ralink/rt2x00/rt2800lib.c:8655:1: warning: the frame
> size of 6456 bytes is larger than 2048 bytes [-Wframe-larger-than=]
> drivers/media/dvb-frontends/stv090x.c:3090:1: warning: the frame size of
> 5872 bytes is larger than 2048 bytes [-Wframe-larger-than=]
> drivers/net/wireless/ralink/rt2x00/rt61pci.c:1647:1: warning: the frame size
> of 5792 bytes is larger than 2048 bytes [-Wframe-larger-than=]
> drivers/media/dvb-frontends/stv090x.c:1595:1: warning: the frame size of
> 5304 bytes is larger than 2048 bytes [-Wframe-larger-than=]
> drivers/scsi/fnic/fnic_trace.c:451:1: warning: the frame size of 5000 bytes
> is larger than 2048 bytes [-Wframe-larger-than=]
> drivers/net/wireless/ralink/rt2x00/rt2800lib.c:2417:1: warning: the frame
> size of 4912 bytes is larger than 2048 bytes [-Wframe-larger-than=]
> drivers/media/dvb-frontends/stv090x.c:4265:1: warning: the frame size of
> 4840 bytes is larger than 2048 bytes [-Wframe-larger-than=]
>
> Comparing against a 3072 byte limit, I get 18 warnings for clang vs 54 for
> gcc-8. The detailed analysis of some of those warnings last year had shown
> that the difference can be traced almost entirely to simple scalar variables
> that use 64 bytes redzone with gcc but only 16 bytes with clang.
Ok, I don't have problem to implement the similar behavior in GCC 9. Looks most
of warnings are in drivers. That should not be problem as I guess KASAN build
is
mainly used in a qemu machine (with syzkaller)? Thus exotic drivers should not
be needed?
I have question about clang where they use for instance:
else if (Size <= 128) Res = Size + 32;
So:
$ cat test.c
int
main (void)
{
char my_char[N];
char *ptr, *ptr2;
{
char my_char2[N];
ptr = &my_char[N - 1];
ptr2 = &my_char2[N - 1];
}
return *(ptr2+8);
}
$ clang -v
clang version 5.0.1 (tags/RELEASE_501/final 312548)
$ clang test.c -fsanitize-address-use-after-scope -fsanitize=address -D N=128
&& ./a.out
=================================================================
==18745==ERROR: AddressSanitizer: stack-buffer-overflow on address
0x7fffffffdb27 at pc 0x0000004e7f29 bp 0x7fffffffd9d0 sp 0x7fffffffd9c8
READ of size 1 at 0x7fffffffdb27 thread T0
#0 0x4e7f28 in main (/tmp/a.out+0x4e7f28)
#1 0x7ffff6eb1f49 in __libc_start_main (/lib64/libc.so.6+0x20f49)
#2 0x41c199 in _start
/home/abuild/rpmbuild/BUILD/glibc-2.26/csu/../sysdeps/x86_64/start.S:120
Address 0x7fffffffdb27 is located in stack of thread T0 at offset 327 in frame
#0 0x4e7d9f in main (/tmp/a.out+0x4e7d9f)
This frame has 2 object(s):
[32, 160) 'my_char'
[192, 320) 'my_char2' <== Memory access at offset 327 overflows this
variable
HINT: this may be a false positive if your program uses some custom stack
unwind mechanism or swapcontext
(longjmp and C++ exceptions *are* supported)
SUMMARY: AddressSanitizer: stack-buffer-overflow (/tmp/a.out+0x4e7f28) in main
Shadow bytes around the buggy address:
0x10007fff7b10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x10007fff7b20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x10007fff7b30: 00 00 00 00 00 00 00 00 00 00 00 00 f1 f1 f1 f1
0x10007fff7b40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x10007fff7b50: f2 f2 f2 f2 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8
=>0x10007fff7b60: f8 f8 f8 f8[f3]f3 f3 f3 00 00 00 00 00 00 00 00
0x10007fff7b70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x10007fff7b80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x10007fff7b90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x10007fff7ba0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x10007fff7bb0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
The middle red zone is only 32B. So I don't understand why 'Size' not used for
red zone
calculation?
