linux-kernel - Re: [PATCH v4 3/3] modversions: treat symbol CRCs as 32 bit quantities on 64 bit archs

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: <CA+55aFzKZySX1VC3YTcZxafDuhLT_HE3voS3UN1eNVh5+6XmNw@mail.gmail.com>
Date:   Tue, 17 Jan 2017 15:47:04 -0800
From:   Linus Torvalds <torvalds@...ux-foundation.org>
To:     Ard Biesheuvel <ard.biesheuvel@...aro.org>
Cc:     Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Michael Ellerman <mpe@...erman.id.au>,
        Jessica Yu <jeyu@...hat.com>,
        Rusty Russell <rusty@...tcorp.com.au>,
        "Suzuki K. Poulose" <suzuki.poulose@....com>,
        Will Deacon <will.deacon@....com>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Benjamin Herrenschmidt <benh@...nel.crashing.org>,
        Paul Mackerras <paulus@...ba.org>,
        Arnd Bergmann <arnd@...db.de>,
        Al Viro <viro@...iv.linux.org.uk>,
        ppc-dev <linuxppc-dev@...ts.ozlabs.org>
Subject: Re: [PATCH v4 3/3] modversions: treat symbol CRCs as 32 bit
 quantities on 64 bit archs

On Tue, Jan 17, 2017 at 11:26 AM, Ard Biesheuvel
<ard.biesheuvel@...aro.org> wrote:
> The modversion symbol CRCs are emitted as ELF symbols, which allows us to
> easily populate the kcrctab sections by relying on the linker to associate
> each kcrctab slot with the correct value.
>
> This has a couple of downsides:

So the whole relocation of the crc is obviously completely crazy, but
you don't actually seem to *change* that. You just work around it, and
you make the symbols 32-bit. The latter part I agree with
whole-heartedly, btw.

But do we really have to accept this relocation insanity?

So I don't actually disagree with this patch 3/3 (turning the whole
crc array into an array of "u32" is clearly the right thing to do),
but the two other patches look oddly broken.

Why are those CRC's relocatable to begin with? Shouldn't they be
absolute values? Why do they get those idiotic relocation things? They
seem to be absolute on x86-64 (just doing a 'nm vmlinux', so I might
be missing something), why aren't they on ppc?

Is there something wrong with our generation script? Can we possibly
do something like

  -       printf("%s__crc_%s = 0x%08lx ;\n", mod_prefix, name, crc);
  +       printf("%s__crc_%s = ABSOLUTE(0x%08lx) ;\n", mod_prefix, name, crc);

in genksyms.c to get rid of the crazty relocation entries?

             Linus