linux-kernel - Re: [PATCH 1/2] sh: align .bss section padding to 8-byte boundary

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] [day] [month] [year] [list]

Message-ID: <CAFULd4YhqH=5eEptwqSFrH=x02W7VKeuca-zBthS_ckLjHWN8g@mail.gmail.com>
Date: Wed, 12 Mar 2025 10:55:56 +0100
From: Uros Bizjak <ubizjak@...il.com>
To: Geert Uytterhoeven <geert@...ux-m68k.org>
Cc: John Paul Adrian Glaubitz <glaubitz@...sik.fu-berlin.de>, Artur Rojek <contact@...ur-rojek.eu>, 
	Yoshinori Sato <ysato@...rs.sourceforge.jp>, Rich Felker <dalias@...c.org>, 
	Daniel Lezcano <daniel.lezcano@...aro.org>, Thomas Gleixner <tglx@...utronix.de>, 
	Geert Uytterhoeven <geert+renesas@...der.be>, "D . Jeff Dionne" <jeff@...esemi.io>, 
	Rob Landley <rob@...dley.net>, linux-sh@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 1/2] sh: align .bss section padding to 8-byte boundary

On Wed, Mar 12, 2025 at 10:47 AM Geert Uytterhoeven
<geert@...ux-m68k.org> wrote:
>
> Hi Uros,
>
> On Wed, 12 Mar 2025 at 09:32, Uros Bizjak <ubizjak@...il.com> wrote:
> > On Wed, Mar 12, 2025 at 9:22 AM John Paul Adrian Glaubitz
> > <glaubitz@...sik.fu-berlin.de> wrote:
> > > > In the original BSS_SECTION(0, PAGE_SIZE, 4), the last argument inserts
> > > > a 4 byte padding after the closing brace of .bss section definition,
> > > > causing the __bss_stop symbol offset to grow, but not the .bss section
> > > > itself:
> > > >
> > > > #define BSS_SECTION(sbss_align, bss_align, stop_align)                        \
> > > >       . = ALIGN(sbss_align);                                          \
> > > >       __bss_start = .;                                                \
> > > >       SBSS(sbss_align)                                                \
> > > >       BSS(bss_align)                                                  \
> > > >       . = ALIGN(stop_align);                                          \
> > > >       __bss_stop = .;
> > >
> > > OK, that's really odd. So, the __bss_stop would be moved to the desired
> > > position but the section itself still remains small? What exactly does the
> > > linker fill the region with? Sounds very strange.
> > >
> > > > TurtleBoard loader is only concerned with the .bss section size - it
> > > > doesn't care about any symbol offsets - and hence this seemingly cryptic
> > > > change (you can display the section size information with
> > > > readelf -t kernel_image).
> > >
> > > Looking at the actual kernel image with readelf is a very good suggestion!
> > >
> > > > The rest of the changes are simply to "inline" the BSS() macro (as I
> > > > needed to access that closing brace), and the former sbss_align,
> > > > bss_align (that's your PAGE_SIZE) and stop_align arguments are passed
> > > > accordingly, the same way they used to be passed before. The only
> > > > visible effect should be the move of ALIGN(stop_align) inside of .bss
> > > > section definition, and the change of stop_align value from 4 to 8.
> > >
> > > OK. FWIW, do you understand what SBSS is for? I couldn't find any explanation
> > > for it.
> >
> > Small BSS section. The compiler can put data objects under a certain
> > size threshold to the .sbss section. Looking at GCC sh config, sh does
> > not use this section.
>
> Hence the moment gcc (or clang) starts using that section, the
> TurtleBoard loader is broken again...

Rest assured that the compiler won't just magically start using SBSS.
This is part of an ABI and in case ABI allows SBSS, the compiler needs
something like:

  if (in_small_data)
    switch_to_section (get_named_section (NULL, ".sbss", 0));

when emitting the declaration.

Uros.