linux-kernel - Re: [PATCH] gcov: fail build on gcov

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, 11 Mar 2021 10:38:51 -0800
From:   Linus Torvalds <torvalds@...ux-foundation.org>
To:     Peter Oberparleiter <oberpar@...ux.ibm.com>
Cc:     Andrew Morton <akpm@...ux-foundation.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] gcov: fail build on gcov_info size mismatch

On Thu, Mar 11, 2021 at 5:07 AM Peter Oberparleiter
<oberpar@...ux.ibm.com> wrote:
>
> This patch adds a compile-time check to ensure that the kernel's version
> of struct gcov_info has the same length as the one used by GCC as
> determined by looking at GCC's assembler output.

So I don't think this is a bad idea, but if you end up test-compiling
something, could we not verify things a bit more?

If you actually build the object file, you should be able to then
check much more. You'll find the pointer to the struct gcov_info in
"__gcov_.fn", which is admittedly hard to then link against a test
program (because of that dot in the name that means that you can't
even use "attribute((alias..))" to generate some other name for it).

But then you could test not only the size, but you could verify that
the "filename" field matches, that the n_functions field should be 1
etc.

IOW, it feels like some ELF munging (possibly even with just scripting
with "objdump") should be able to add verification for a bit more than
just the size.

I guess the size is kind of critical, because of how GCOV_COUNTERS has
changed, but if any other layout issue changes, the size might not be
all that relevant.

For example, looking at the current "struct gcov_info" gcc uses, it's
very badly packed, with 32-bit fields literally interspersed with
64-bit fields. So I could easily imagine that somebody goes "heyt,
guys, we need to add another GCOV counter, but we don't need to change
the size of the gcov_info, because we can just out the "version" and
"stamp" integers next to each other and getting rid of the padding
makes up for the extra counter".

I dunno. The gcov code has obviously never actually done anything like
this before, so maybe I'm just taking the "we could verify
_something_" and my reaction is that there could be even more
verification if we really want to go down that rabbit hole..

           Linus