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
| ||
|
Message-ID: <20210128213409.qxnclchjyq6v23up@treble> Date: Thu, 28 Jan 2021 15:34:09 -0600 From: Josh Poimboeuf <jpoimboe@...hat.com> To: Linus Torvalds <torvalds@...ux-foundation.org> Cc: Masahiro Yamada <masahiroy@...nel.org>, Michal Marek <michal.lkml@...kovi.net>, Linux Kernel Mailing List <linux-kernel@...r.kernel.org>, Kees Cook <keescook@...omium.org>, linux-hardening@...r.kernel.org, Linux Kbuild mailing list <linux-kbuild@...r.kernel.org>, Peter Zijlstra <peterz@...radead.org>, Justin Forbes <jforbes@...hat.com>, Ondrej Mosnacek <omosnace@...hat.com>, Greg Kroah-Hartman <gregkh@...uxfoundation.org>, Christoph Hellwig <hch@...radead.org>, Miroslav Benes <mbenes@...e.cz>, David Laight <David.Laight@...lab.com>, Jessica Yu <jeyu@...nel.org> Subject: Re: [PATCH RFC] kbuild: Prevent compiler mismatch with external modules On Thu, Jan 28, 2021 at 01:23:11PM -0800, Linus Torvalds wrote: > On Thu, Jan 28, 2021 at 1:03 PM Linus Torvalds > <torvalds@...ux-foundation.org> wrote: > > > > I really think the whole compiler version check is purely voodoo programming. > > .. but there are obviously potentially things we - in the kernel - do > that may make certain compiler versions incompatible. We long long ago > used to have things like "you can't have an empty struct because gcc > version x.y.z doesn't support it", so even a UP spinlock would be > > typedef struct { int gcc_is_buggy; } raw_spinlock_t; > > but only if you compiled it with a version of gcc older than 3.0. So > compiling one file with one compiler, and another with a newer one, > would result in the data structures simply not having the same layout. > > That's not because of compiler versions per se, it's because of our > version checks. Right, this is what I'm trying to say. We have features based on compiler version checks. Peterz pointed out asm goto as a previous example. > THAT workaround is long gone, but I didn't check what other ones we > might have now. But the gcc version checks we _do_ have are not > necessarily about major versions at all (ie I trivially found checks > for 4.9, 4.9.2, 5.1, 7.2 and 9.1). Then maybe the check should be same major.minor? And convert it to a strongly worded warning/disclaimer? -- Josh
Powered by blists - more mailing lists