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]

Message-ID: <63bc4b60-ca3f-2895-b202-cabd9a14e3ca@gmail.com>
Date:   Mon, 18 Dec 2017 11:38:20 +0100
From:   Marek Vasut <marek.vasut@...il.com>
To:     Arnd Bergmann <arnd@...db.de>
Cc:     Richard Weinberger <richard@....at>,
        David Woodhouse <dwmw2@...radead.org>,
        Brian Norris <computersforpeace@...il.com>,
        Boris Brezillon <boris.brezillon@...e-electrons.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 12/18/2017 11:29 AM, Arnd Bergmann wrote:
> On Mon, Dec 18, 2017 at 10:18 AM, Marek Vasut <marek.vasut@...il.com> wrote:
>> On 12/18/2017 10:16 AM, Arnd Bergmann wrote:
>>> 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.
> ...
>>>>>
>>>>> 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.
>>
>> Wouldn't it make more sense to fix the compiler instead ?
>> This still feels like we're fixing a bug at the wrong place ...
> 
> See above: the compiler is fixed in the gcc-8.x release branch,
> which won't be out until next spring. People use all kinds of versions
> as old as gcc-4.3, even if the fix was backported to older compilers
> (which it is not), most users never rebuild their toolchains to get the
> latest bugfix releases.
> 
> For instance, the Android SDK comes with prebuilt binaries of
> a gcc-4.9-prerelease version that has many known bugs that
> were fixed either by the time the official 4.9 release happened,
> or in one of the bugfix releases following it.

But doesn't this mean we're taking the OpenSSL path (which didn't work
out well for them IIRC) ?

I don't have a better solution for this though ...

-- 
Best regards,
Marek Vasut