linux-kernel - Re: [RFC] kasan stack overflow warnings again: READ

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAK8P3a3zN+LF8s=zqy99+wPXoBP4FVjetchYzNVyVvr7K6jSyA@mail.gmail.com>
Date:   Wed, 15 Feb 2017 11:34:26 +0100
From:   Arnd Bergmann <arnd@...db.de>
To:     Dmitry Vyukov <dvyukov@...gle.com>
Cc:     "kasan-dev@...glegroups.com" <kasan-dev@...glegroups.com>,
        Andrey Ryabinin <aryabinin@...tuozzo.com>,
        Alexander Potapenko <glider@...gle.com>,
        LKML <linux-kernel@...r.kernel.org>,
        Christian Borntraeger <borntraeger@...ibm.com>
Subject: Re: [RFC] kasan stack overflow warnings again: READ_ONCE(), typecheck()

On Wed, Feb 15, 2017 at 10:18 AM, Dmitry Vyukov <dvyukov@...gle.com> wrote:
> On Wed, Feb 15, 2017 at 12:03 AM, Arnd Bergmann <arnd@...db.de> wrote:

> Hi Arnd,
>
> Frankly it looks like something that needs to be fixed in compilers.
> However, that probably won't happen in near future.
> Our bet is on clang where we would be interested in fixing such issues.
>
> Alexander, can you please check how clang compares with gcc with asan
> stack instrumentation on typecheck and READ_ONCE?
> If clang introduces additional redzones due to code in typecheck and
> READ_ONCE, then it looks like something that we need to fix. Not sure
> why typecheck affects codegen at all...
>
> Re committing this change: Arnd, do you have an estimation on number
> of changes we will need to land to enable the warning? If it's
> handful, then it may be worth pursuing (but we still need a proper
> impl for READ_ONCE).

My current estimate is only a handful of patches to enable
CONFIG_FRAME_WARN=3072 with a clean build, and maybe a few dozen
more to get down to 2048 with gcc-7.0.1 (no idea for older versions).

What I'm looking at now is this set of remaining warnings (>3072 bytes)
and 24 other files >2048:

drivers/gpu/drm/i915/gvt/handlers.c:2200:1: error: the frame size of
30448 bytes is larger than 3000 bytes
drivers/media/usb/em28xx/em28xx-dvb.c:2061:1: error: the frame size of
4264 bytes is larger than 3000 bytes
drivers/staging/unisys/visorbus/visorchipset.c:1466:1: error: the
frame size of 3008 bytes is larger than 3000 bytes
fs/ocfs2/super.c:1219:1: error: the frame size of 3232 bytes is larger
than 3000 bytes
lib/lz4/lz4_compress.c:883:1: error: the frame size of 6696 bytes is
larger than 3000 bytes
lib/lz4/lz4hc_compress.c:579:1: error: the frame size of 5576 bytes is
larger than 3000 bytes

and this set of patches I have applied locally, most of which need
some more work:

# shown here earlier, need work
rewrite READ_ONCE/WRITE_ONCE
typecheck.h: avoid local variables in typecheck() macro
# needs rewrite to use __uninline_for_kasan
[SUBMITTED 20170208] netlink: move nla_put_{u8,u16,u32} out of line
# pending for 4.11 or 4.12
[SUBMITTED 20170208] [media] tc358743: fix register i2c_rd/wr functions
[SUBMITTED 20170214] rt2500usb: don't mark register accesses as inline
# these just add more __uninline_for_kasan in driver specific code
staging: dgnc: reduce stack usage with KASAN
[media] i2c: cx25840: avoid stack overflow with KASAN
[media] tuners: reduce stack usage with kasan
[media] i2c: ks0127: reduce stack frame size
[media] dvb-frontends: reduce stack size in i2c access
[media] r820t: rewrite register access to reduce stack size
tty: kbd: reduce stack size with KASAN

     Arnd