linux-kernel - Re: [PATCH] libosd: Remove ignored _

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: <1538503063.193396.6.camel@acm.org>
Date:   Tue, 02 Oct 2018 10:57:43 -0700
From:   Bart Van Assche <bvanassche@....org>
To:     Nick Desaulniers <ndesaulniers@...gle.com>
Cc:     Nathan Chancellor <natechancellor@...il.com>, ooo@...ctrozaur.com,
        "James E.J. Bottomley" <jejb@...ux.vnet.ibm.com>,
        "Martin K. Petersen" <martin.petersen@...cle.com>,
        linux-scsi@...r.kernel.org, LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] libosd: Remove ignored __weak attribute

On Tue, 2018-10-02 at 10:24 -0700, Nick Desaulniers wrote:
> On Mon, Oct 1, 2018 at 6:16 PM Bart Van Assche <bvanassche@....org> wrote:
> > Additionally, zero initializers should be left out to minimize
> > the size of object files.
> 
> Sorry, my understanding was that global variables either occupy the
> .bss section or the .data section, depending on whether they were
> zero-initialized vs initialized to non-zero, respectively (where
> non-initialized are treated as zero initialized).  Looks like without
> the explicit zero initialization, compilers will put the symbols in a
> "common" section, which `man 1 nm` says is also unitialized data.  I
> didn't think .bss sections occupied space in an object file or binary;
> the kernel's loader would set up the mappings at execution?  Can you
> clarify?

Explicitly initialized global and static variables end up in the .data
section and need space in that section. That is not the case if the
initializer is left out and these variables end up in the .bss section.
>From https://en.wikipedia.org/wiki/.bss:

"In computer programming, the name .bss or bss is used by many compilers
and linkers for the portion of an object file or executable containing
statically-allocated variables that are not explicitly initialized to any
value. It is often referred to as the "bss section" or "bss segment".

Typically only the length of the bss section, but no data, is stored in
the object file."

This is why checkpatch warns if a global or static variable is initialized
explicitly to zero. From scripts/checkpatch.pl:

our $zero_initializer = qr{(?:(?:0[xX])?0+$Int_type?|NULL|false)\b};

# check for global initialisers.

                if ($line =~ /^\+$Type\s*$Ident(?:\s+$Modifier)*\s*=\s*($zero_initializer)\s*;/) {
                        if (ERROR("GLOBAL_INITIALISERS",
                                  "do not initialise globals to $1\n" . $herecurr) && $fix) {
                                $fixed[$fixlinenr] =~ s/(^.$Type\s*$Ident(?:\s+$Modifier)*)\s*=\s*$zero_initializer\s*;/$1;/;
                        }
                }

# check for static initialisers.

                if ($line =~ /^\+.*\bstatic\s.*=\s*($zero_initializer)\s*;/) {
                        if (ERROR("INITIALISED_STATIC",
                                  "do not initialise statics to $1\n" . $herecurr) && $fix) {
                                $fixed[$fixlinenr] =~ s/(\bstatic\s.*?)\s*=\s*$zero_initializer\s*;/$1;/;
                        }
                }

Bart.