Re: Output section type (READONLY)

[Luca Boccassi <bluca@debian.org>]

[-- Attachment #1: Type: text/plain, Size: 4137 bytes --]

On Wed, 2022-02-02 at 16:54 +0000, Michael Matz wrote:
> Hello,
> 
> On Tue, 1 Feb 2022, Fangrui Song wrote:
> 
> > On 2022-02-01, Luca Boccassi wrote:
> > > > > For READONLY, I am thinking more in line with "whether we need this
> > > > > feature at all"... If no input has SHF_WRITE, the output naturally
> > > > does
> > > > > not have SHF_WRITE; if an input has SHF_WRITE, chancing the output
> > > > to
> > > > > non-SHF_WRITE is weird and error-prone.
> > > > 
> > > > I do not know if this counts as a *justified* use of READONLY, but it
> > > > was
> > > > used recently in an attempt to add a new feature to Fedora rawhide:
> > > > 
> > > > 
> > > > https://fedoraproject.org/wiki/Changes/Package_information_on_ELF_objects#New_system:_.note.package
> > > > 
> > > > The feature used a custom linker script fragment to add a note
> > > > section
> > > > into the executable being created, and this script used the READONLY
> > > > keyword:
> > > > 
> > > >    SECTIONS
> > > >    {
> > > >      .note.package (READONLY) : ALIGN(4) {
> > > >          BYTE(0x04) BYTE(0x00) BYTE(0x00) BYTE(0x00) /* Length of
> > > > Owner including NUL */
> > > >   [...]
> > > >      }
> > > >    }
> > > >    INSERT AFTER .note.gnu.build-id;
> > 
> > Yes, I recently learned that Fedora started to use (READONLY).
> > The usage feels strange to me as .note.package should not have the
> > SHF_WRITE flag, even without READONLY....
> > 
> > In https://sourceware.org/bugzilla/show_bug.cgi?id=26378#c11 , Alan
> > changed such sections to be read-only by default in 2020 to support a
> > Linux use case. I do not understand why a new keyword has to be
> > invented...
> 
> Agreed.
> 
> > The next thing I feel uncomfortable with is the abuse of .note* indicates
> > a SHT_NOTE section. The type, in my opinion, should be explicitly
> > specified. In ELF, attributes are identified as well known integers.
> > The magic section prefix ".note" is contrary to this.
> > 
> > I shall add a note that gold doesn't magically set an output section .note*
> > to SHT_NOTE and this behavior makes a lot of sense to me.
> > 
> > To allow forward progress, I created
> > https://sourceware.org/pipermail/binutils/2022-February/119591.html
> > (ld: Support customized output section type) and I'd recommend that the
> > linker script fragment
> > 
> >    .note.package (READONLY) : ALIGN(4) {
> > 
> > switches to
> > 
> >    .note.package (TYPE=SHT_NOTE) : ALIGN(4) {
> 
> Also agreed.
> 
> (We can't remove the implicit .note* -> SHT_NOTE behaviour anymore, but it 
> shouldn't have been there from the beginning).
> 
> > > > This turned out to be problematic however as gold does not support
> > > > the
> > > > READONLY attribute, nor the INSERT AFTER directive...
> > 
> > This is the reason that I really recommend a synthesized .o file,
> > instead of a synthesized output section description using data
> > commands...
> 
> More agreement.  I also think that the synthesized sections should rather 
> be thought of as and handled like (by ld) input sections, going through 
> the normal linker processing (which would remove the need for "INSERT 
> AFTER").  That's a largish change, so not something we can do now anymore, 
> probably.

Compiled object do not work and cannot possibly work sanely in this
context. It is hard enough to make a simple and trivial linker script
work reliably across ~30.000 packages with god-knows-how-many different
build systems on a dozen different architectures, so it's just not
going to happen, sorry. Linker scripts exist and, to the best of my
knowledge, are still supported and supposed to work, so we are using
them.

> IOW: I think the introduction of READONLY was ill-advised :-/  But, ... 
> well :)

If you have an alternative solution to make a linker script create a
read-only note section to be inserted after another section we'd love
to hear it. So far we haven't found any, but it's possible we missed
something, of course.

-- 
Kind regards,
Luca Boccassi

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 833 bytes --]