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, 1 Dec 2016 23:39:42 +1100
From:   Nicholas Piggin <npiggin@...il.com>
To:     Stanislav Kozina <skozina@...hat.com>
Cc:     Don Zickus <dzickus@...hat.com>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        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 Thu, 1 Dec 2016 12:33:02 +0100
Stanislav Kozina <skozina@...hat.com> wrote:

> On 12/01/2016 12:09 PM, Nicholas Piggin wrote:
> > On Thu, 1 Dec 2016 11:48:09 +0100
> > Stanislav Kozina <skozina@...hat.com> wrote:
> >  
> >> On 12/01/2016 05:13 AM, Don Zickus wrote:
> >>
> >> ...
> >>  
> >>> I think GregKH pointed to one such tool, libabigail?  We are working on
> >>> others too.  
> >> I should mention one of the others here:
> >> https://github.com/skozina/kabi-dw
> >>
> >> It's quite comparable to libabigail in the way it works, the main
> >> differences are:
> >>    - written in pure C
> >>    - depends only on elf-utils and flex/yacc
> >>    - it's much simpler (4k LOC)
> >>    - stores the type information in the text files and compares those
> >> instead of directly comparing two sets of DWARF data  
> > Now this seems much better for distro ABI checking.
> >
> > The next question is, do they need any kernel support for rare cases
> > where they do have to break the ABI of an export? Simple rename of the
> > function with a _v2 postfix might be enough. We could retain some per
> > symbol versioning in the kernel if needed, but how much would it
> > actually help?  
> 
> The biggest pain point AFAICT is to identify what types (functions, 
> structs, enums, ...) should be considered a part of the stable ABI.

Sure. This is something an automated checker can't solve completely.
Any changes would have to be considered in terms of their impact to
the ABI. It's not just data but also instruction changes involved.

This is policy that should not be mandated by the kernel. Which is
why I'm in favor of using tools like this and just providing mechanism
so distros can implement their own polices.

> And 
> the problem with modversions is that it pulls in just everything which 
> gets (accidentally?) #included in the source file.

I think that's SRCVERSION which is something else. But modversions
has problems too.

> The actual ABI maintenance is a different problem, but there are many 
> possible approaches, the _v2 suffix being one of them.

Would be good to get a consensus on that too.

Thanks,
Nick

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ