linux-kernel - Re: LOCALVERSION_AUTO considered harmful

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] [day] [month] [year] [list]

Date:	Mon, 12 Apr 2010 10:03:03 -0700 (PDT)
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Pavel Machek <pavel@....cz>
cc:	Thomas Gleixner <tglx@...utronix.de>,
	Geert Uytterhoeven <geert@...ux-m68k.org>,
	Alexey Dobriyan <adobriyan@...il.com>,
	kernel list <linux-kernel@...r.kernel.org>,
	Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: LOCALVERSION_AUTO considered harmful

On Mon, 12 Apr 2010, Pavel Machek wrote:

> Hi!
> 
> > > > > That's conditional BS.
> > > > > Turn off CONFIG_MODVERSIONS already.
> > > > 
> > > > Yeah, I disabled it ages ago. Even then (before git, probably even
> > > > before bitkeeper)
> > > > I had hard times inserting modules...
> > > 
> > > I _had_ it off
> > > 
> > >  # CONFIG_MODVERSIONS is not set
> > > 
> > > It seems some checking survives CONFIG_MODVERSIONS unset and that
> > > checking is strict enough to refuse module load after one "make
> > > modules" with LOCALVERSION_AUTO on...
> > 
> > So instead of fixing the CONFIG_MODVERSIONS=n case you go the easy way
> > of killing LOCALVERSION_AUTO ? Brilliant.
> 
> In previous discussion, I was told that there's no bug to fix, that
> everything works as intended.

The problem is that you guys are looking at CONFIG_MODVERSIONS the wrong 
way around.

It's the _off_ case that is broken. Always was, always will be.

If CONFIG_MODVERSIONS is off, we remove the symbol versioning, and replace 
it with the _insane_ kernel version check. That is never valid. The fact 
that the kernel version is the same doesn't mean that the module will 
work, since we often do lots of changes within the same version.

So the solution is to say CONFIG_MODVERSIONS=y, and everybody is happy. 
Your modules will actually test things that _matter_, and will stop 
loading if the data types or function prototypes have changed. 

		Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/