On 12/18/2017 10:16 AM, Arnd Bergmann wrote: > On Sun, Dec 17, 2017 at 9:34 PM, Richard Weinberger <richard@xxxxxx> 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@xxxxxxxxxxxxxxx >>> Signed-off-by: Arnd Bergmann <arnd@xxxxxxxx> >> >> Acked-by: Richard Weinberger <richard@xxxxxx> > > 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 ... -- Best regards, Marek Vasut