linux-kernel - Re: [PATCH] [stable 4.14] turn off -Wattribute-alias

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:   Thu, 26 Jul 2018 12:02:42 +0200
From:   Arnd Bergmann <arnd@...db.de>
To:     Greg KH <gregkh@...uxfoundation.org>
Cc:     "# 3.4.x" <stable@...r.kernel.org>, Michal Marek <mmarek@...e.com>,
        Linux Kbuild mailing list <linux-kbuild@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] [stable 4.14] turn off -Wattribute-alias

On Thu, Jul 26, 2018 at 11:22 AM, Greg KH <gregkh@...uxfoundation.org> wrote:
> On Thu, Jul 26, 2018 at 10:13:22AM +0200, Arnd Bergmann wrote:
>> Starting with gcc-8.1, we get a warning about all system call definitions,
>> which use an alias between functions with incompatible prototypes, e.g.:
>>
>> In file included from ../mm/process_vm_access.c:19:
>> ../include/linux/syscalls.h:211:18: warning: 'sys_process_vm_readv' alias between functions of incompatible types 'long int(pid_t,  const struct iovec *, long unsigned int,  const struct iovec *, long unsigned int,  long unsigned int)' {aka 'long int(int,  const struct iovec *, long unsigned int,  const struct iovec *, long unsigned int,  long unsigned int)'} and 'long int(long int,  long int,  long int,  long int,  long int,  long int)' [-Wattribute-alias]
>>   asmlinkage long sys##name(__MAP(x,__SC_DECL,__VA_ARGS__)) \
>>                   ^~~
>> ../include/linux/syscalls.h:207:2: note: in expansion of macro '__SYSCALL_DEFINEx'
>>   __SYSCALL_DEFINEx(x, sname, __VA_ARGS__)
>>   ^~~~~~~~~~~~~~~~~
>> ../include/linux/syscalls.h:201:36: note: in expansion of macro 'SYSCALL_DEFINEx'
>>  #define SYSCALL_DEFINE6(name, ...) SYSCALL_DEFINEx(6, _##name, __VA_ARGS__)
>>                                     ^~~~~~~~~~~~~~~
>> ../mm/process_vm_access.c:300:1: note: in expansion of macro 'SYSCALL_DEFINE6'
>>  SYSCALL_DEFINE6(process_vm_readv, pid_t, pid, const struct iovec __user *, lvec,
>>  ^~~~~~~~~~~~~~~
>> ../include/linux/syscalls.h:215:18: note: aliased declaration here
>>   asmlinkage long SyS##name(__MAP(x,__SC_LONG,__VA_ARGS__)) \
>>                   ^~~
>> ../include/linux/syscalls.h:207:2: note: in expansion of macro '__SYSCALL_DEFINEx'
>>   __SYSCALL_DEFINEx(x, sname, __VA_ARGS__)
>>   ^~~~~~~~~~~~~~~~~
>> ../include/linux/syscalls.h:201:36: note: in expansion of macro 'SYSCALL_DEFINEx'
>>  #define SYSCALL_DEFINE6(name, ...) SYSCALL_DEFINEx(6, _##name, __VA_ARGS__)
>>                                     ^~~~~~~~~~~~~~~
>> ../mm/process_vm_access.c:300:1: note: in expansion of macro 'SYSCALL_DEFINE6'
>>  SYSCALL_DEFINE6(process_vm_readv, pid_t, pid, const struct iovec __user *, lvec,
>>
>> This is really noisy and does not indicate a real problem. In the latest
>> mainline kernel, this was addressed by commit bee20031772a ("disable
>> -Wattribute-alias warning for SYSCALL_DEFINEx()"), which seems too invasive
>> to backport.
>
> Too invasive?
>
> Here's the diffstat:
>          include/linux/compat.h   |    8 +++++++-
>          include/linux/syscalls.h |    4 ++++
>          2 files changed, 11 insertions(+), 1 deletion(-)
>
> That seems almost trivial to backport.  Did you try it and it caused
> other problems?
>
> Where ever possible, I always want to use the upstream commits.

I forward ported that patch a few times across kernels when that macro
changed in subtle ways. This was particularly tricky as some using the
new macro inside of another macro sometimes has different effects
based on seemingly unrelated changes: in particular the addition of
__MAP() in COMPAT_SYSCALL_DEFINEx that I had to do to work
around gcc pr83256 can easily break.

It also depends on commit 8793bb7f4a9d ("kbuild: add macro for
controlling warnings to linux/compiler.h") before it, which is not long
but does add new infrastructure.

      Arnd