linux-kernel - Re: [PATCH] mtd: cfi: convert inline functions to macros

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]

Date:   Mon, 18 Dec 2017 10:16:41 +0100
From:   Arnd Bergmann <arnd@...db.de>
To:     Richard Weinberger <richard@....at>
Cc:     David Woodhouse <dwmw2@...radead.org>,
        Brian Norris <computersforpeace@...il.com>,
        Boris Brezillon <boris.brezillon@...e-electrons.com>,
        Marek Vasut <marek.vasut@...il.com>,
        Cyrille Pitchen <cyrille.pitchen@...ev4u.fr>,
        "# 3.4.x" <stable@...r.kernel.org>,
        linux-mtd <linux-mtd@...ts.infradead.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] mtd: cfi: convert inline functions to macros

On Sun, Dec 17, 2017 at 9:34 PM, Richard Weinberger <richard@....at> wrote:
> Am Mittwoch, 11. Oktober 2017, 15:54:10 CET schrieb Arnd Bergmann:
>> The map_word_() functions, dating back to linux-2.6.8, try to perform
>> bitwise operations on a 'map_word' structure. This may have worked
>> with compilers that were current then (gcc-3.4 or earlier), but end
>> up being rather inefficient on any version I could try now (gcc-4.4 or
>> higher). Specifically we hit a problem analyzed in gcc PR81715 where we
>> fail to reuse the stack space for local variables.
>>
>> This can be seen immediately in the stack consumption for
>> cfi_staa_erase_varsize() and other functions that (with CONFIG_KASAN)
>> can be up to 2200 bytes. Changing the inline functions into macros brings
>> this down to 1280 bytes.  Without KASAN, the same problem exists, but
>> the stack consumption is lower to start with, my patch shrinks it from
>> 920 to 496 bytes on with arm-linux-gnueabi-gcc-5.4, and saves around
>> 1KB in .text size for cfi_cmdset_0020.c, as it avoids copying map_word
>> structures for each call to one of these helpers.
>>
>> With the latest gcc-8 snapshot, the problem is fixed in upstream gcc,
>> but nobody uses that yet, so we should still work around it in mainline
>> kernels and probably backport the workaround to stable kernels as well.
>> We had a couple of other functions that suffered from the same gcc bug,
>> and all of those had a simpler workaround involving dummy variables
>> in the inline function. Unfortunately that did not work here, the
>> macro hack was the best I could come up with.
>>
>> It would also be helpful to have someone to a little performance testing
>> on the patch, to see how much it helps in terms of CPU utilitzation.
>>
>> Link: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81715
>> Cc: stable@...r.kernel.org
>> Signed-off-by: Arnd Bergmann <arnd@...db.de>
>
> Acked-by: Richard Weinberger <richard@....at>

Thanks!

> Marek, I know you are not super happy with this patch but IMHO this is the
> solution with the least hassle.
> While functions offer better type checking I think this functions are trivial
> enough to exist as macros too.
> Also forcing users to upgrade/fix their compilers is only possible in a
> perfect world.

Right. To clarify, this is a potential security issue, as it might be used to
construct a stack overflow to cause privilege escalation when combined
with some other vulnerabilities. I'd definitely want this backported to
stable kernels as a precaution, and I'm preparing a patch to warn
about this kind of problem again in 'allmodconfig' kernels that
currently disable the warning on arm64 and x86.

       Arnd