linux-kernel - Re: [PATCH v2] Compiler Attributes: don't pollute userspace with macro definitions

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, 13 Dec 2018 14:25:17 -0800
From:   Nick Desaulniers <ndesaulniers@...gle.com>
To:     Miguel Ojeda <miguel.ojeda.sandonis@...il.com>
Cc:     liuxiaozhou@...edance.com, Greg KH <gregkh@...uxfoundation.org>,
        Masahiro Yamada <yamada.masahiro@...ionext.com>,
        Luc Van Oostenryck <luc.vanoostenryck@...il.com>,
        paul.burton@...s.com, Arnd Bergmann <arnd@...db.de>,
        LKML <linux-kernel@...r.kernel.org>,
        Linus Torvalds <torvalds@...ux-foundation.org>
Subject: Re: [PATCH v2] Compiler Attributes: don't pollute userspace with
 macro definitions

>> compiling error
>> showing "unknown type name ‘__gnu_inline’" will pop up, if userspace
>> somehow includes <linux/compiler.h>.

Oops.

> If not, I can pick it up in compiler-attributes tree linux-next.

That's probably the best, unless we'd like this fix in mainline ASAP?

Moving the __KERNEL__ guard should not affect the kernel, only what
userspace sees.  __gnu_inline only affects which
implementation/definition you get, so even if userspace doesn't know
what the kernel's inline is redefined to, it should not matter as
userspace should only ever care about the function signature, which
does not change between our definitions of inline.

Acked-by: Nick Desaulniers <ndesaulniers@...gle.com>

-- 
Thanks,
~Nick Desaulniers