linux-kernel - Re: [PATCH] x86/kbuild: enable modversions for symbols exported from asm

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]

Message-ID: <20161201041325.GX35881@redhat.com>
Date:   Wed, 30 Nov 2016 23:13:25 -0500
From:   Don Zickus <dzickus@...hat.com>
To:     Linus Torvalds <torvalds@...ux-foundation.org>
Cc:     Nicholas Piggin <npiggin@...il.com>, skozina@...hat.com,
        Ben Hutchings <ben@...adent.org.uk>,
        Michal Marek <mmarek@...e.com>,
        Adam Borowski <kilobyte@...band.pl>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Linux Kbuild mailing list <linux-kbuild@...r.kernel.org>,
        Debian kernel maintainers <debian-kernel@...ts.debian.org>,
        "linux-arch@...r.kernel.org" <linux-arch@...r.kernel.org>,
        Arnd Bergmann <arnd@...db.de>, Ingo Molnar <mingo@...nel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] x86/kbuild: enable modversions for symbols exported from
 asm

On Wed, Nov 30, 2016 at 10:40:02AM -0800, Linus Torvalds wrote:
> On Wed, Nov 30, 2016 at 10:18 AM, Nicholas Piggin <npiggin@...il.com> wrote:
> >
> > Here's an initial rough hack at removing modversions. It gives an idea
> > of the complexity we're carrying for this feature (keeping in mind most
> > of the lines removed are generated parser).
> 
> You definitely don't have to try to convince me. We've had many issues
> with modversions over the years. This was just the "last drop" as far
> as I'm concerned, we've had random odd crc generation failures due to
> some build races too.
> 
> > In its place I just added a simple config option to override vermagic
> > so distros can manage it entirely themselves.
> 
> So at least Fedora doesn't even enable CONFIG_MODVERSIONS as-is. I'm
> _hoping_ it's just Debian that wants this, and we'd need to get some
> input from the Debian people whether that "control vermagic" is
> sufficient? I suspect it isn't, but I can't come up with any simple
> alternate model either..

Oddly, I just posted a patch to enable this for Fedora and then someone
pointed me at this thread. :-/

Sorry for chiming in late, but yes RHEL is a big user of MODVERSIONS for our
kabi protection work.  Despite our best intentions we still have lots of
partners and customers that provide value-add out-of-tree drivers to their
customers.  These module builders requested we have a mechanism to allow
rolling modules forward for each of our minor RHEL updates without breaking
their drivers.

They requested this to save time and money on rebuilding and retesting.  It
also helps deal with situations where RHEL puts out a security fix or new
minor release and the provider of OOT driver has not released the
appropriate update.  Customers like the ability to roll their special
drivers forward quickly to their schedule.

Now we don't protect every symbol, just a select few that our meets our
customers needs (and developers willing to support it).

Anyway, MODVERSIONS is our way of protecting our kabi for the last 10 years.
It isn't perfect and we have fixed the genksyms tool over the years, but so
far it mostly works fine.

I am not sure what 'control vermagic' is, but it sounds like a string check,
which won't protect against the boatload of backports we do to structs,
enums, and functions.

Currently we are exploring various ways to get smarter here.  The genksyms
tool has its limitations and handling kabi hacks in RHEL is getting
tiresome.

I think GregKH pointed to one such tool, libabigail?  We are working on
others too.

Circling back to enabling MODVERSIONS in Fedora, that was to start the
process of syncing Fedora with RHEL stuff in preparation for smarter tools.

If you take away MODVERSIONS, that would put a damper in our work, but
easily carried privately (much like MODSIGNING for 8 years until it went
upstream :-) ).

We would prefer to work with various folks to figure out a better solution
to solve our/others needs.  Anyone interested in working with Red Hat should
contact Stanislav Kozina (skozina@...hat.com) (cc'd above) and cc myself.

Cheers,
Don

> 
> I'm also somewhat surprised that it's Debian that has this problem,
> considering how Debian is usually the distro that is _least_ receptive
> to various non-free binaries.
> 
>             Linus