SH FDPIC ABI spec/binutils and kernel conflict on flag definitions

SH FDPIC ABI spec/binutils and kernel conflict on flag definitions

[Rich Felker]

In the ELF Header part of the SH FDPIC ABI document, it's stated that
EF_SH_FDPIC|EF_SH_PIC means each LOAD segment can be independently
positioned, while EF_SH_FDPIC by itself (without EF_SH_PIC) means the
relative position of LOAD segments with respect to each other is fixed
(like in normal ELF usage). This seems to match what binutils outputs.

However the kernel contains the code (arch/sh/include/asm/elf.h):

#define elf_check_const_displacement(x) ((x)->e_flags & EF_SH_PIC)

and (fs/binfmt_elf_fdpic.c):

	if (elf_check_const_displacement(&exec_params.hdr))
		exec_params.flags |= ELF_FDPIC_FLAG_CONSTDISP;

which does exactly the opposite: the presence of the EF_SH_PIC flag,
rather than absence of it, causes the kernel to treat the binary as
one requiring "constant displacement" between LOAD segments.

If my analysis is correct, how should this be fixed? It seems to me
the kernel is clearly wrong, but it might also be considered the de
facto ABI. Is there any way forward that allows fixing this bug (which
defeats the whole purpose of FDPIC) without breaking existing usage?
Or is there no existing usage to care about?

Rich

Re: SH FDPIC ABI spec/binutils and kernel conflict on flag definitions

[Nick Clifton]

Hi Rich,

> In the ELF Header part of the SH FDPIC ABI document, it's stated that
> EF_SH_FDPIC|EF_SH_PIC means each LOAD segment can be independently
> positioned, while EF_SH_FDPIC by itself (without EF_SH_PIC) means the
> relative position of LOAD segments with respect to each other is fixed
> (like in normal ELF usage). This seems to match what binutils outputs.
>
> However the kernel contains the code (arch/sh/include/asm/elf.h):
>
> #define elf_check_const_displacement(x) ((x)->e_flags & EF_SH_PIC)
>
> and (fs/binfmt_elf_fdpic.c):
>
> 	if (elf_check_const_displacement(&exec_params.hdr))
> 		exec_params.flags |= ELF_FDPIC_FLAG_CONSTDISP;
>
> which does exactly the opposite: the presence of the EF_SH_PIC flag,
> rather than absence of it, causes the kernel to treat the binary as
> one requiring "constant displacement" between LOAD segments.
>
> If my analysis is correct, how should this be fixed? It seems to me
> the kernel is clearly wrong, but it might also be considered the de
> facto ABI.

I think that adopting the kernel's behaviour as correct would set a 
dangerous precedent.  A published ABI should be followed, and if the 
kernel does not implement it, then the kernel is wrong.

> Is there any way forward that allows fixing this bug (which
> defeats the whole purpose of FDPIC) without breaking existing usage?

Maybe a kernel tuning option ?  (I am not familiar with kernel 
development so maybe this idea is a non-starter).

> Or is there no existing usage to care about?

I could not say for sure, but I imagine that there must be at least some 
people who are using SH linux at the moment.

Cheers
   Nick

Re: SH FDPIC ABI spec/binutils and kernel conflict on flag definitions

[Rich Felker]

On Thu, Sep 10, 2015 at 12:57:09PM +0100, Nick Clifton wrote:
> Hi Rich,
> 
> >In the ELF Header part of the SH FDPIC ABI document, it's stated that
> >EF_SH_FDPIC|EF_SH_PIC means each LOAD segment can be independently
> >positioned, while EF_SH_FDPIC by itself (without EF_SH_PIC) means the
> >relative position of LOAD segments with respect to each other is fixed
> >(like in normal ELF usage). This seems to match what binutils outputs.
> >
> >However the kernel contains the code (arch/sh/include/asm/elf.h):
> >
> >#define elf_check_const_displacement(x) ((x)->e_flags & EF_SH_PIC)
> >
> >and (fs/binfmt_elf_fdpic.c):
> >
> >	if (elf_check_const_displacement(&exec_params.hdr))
> >		exec_params.flags |= ELF_FDPIC_FLAG_CONSTDISP;
> >
> >which does exactly the opposite: the presence of the EF_SH_PIC flag,
> >rather than absence of it, causes the kernel to treat the binary as
> >one requiring "constant displacement" between LOAD segments.
> >
> >If my analysis is correct, how should this be fixed? It seems to me
> >the kernel is clearly wrong, but it might also be considered the de
> >facto ABI.
> 
> I think that adopting the kernel's behaviour as correct would set a
> dangerous precedent.  A published ABI should be followed, and if the
> kernel does not implement it, then the kernel is wrong.

I tend to agree. However it also seems to be backwards for FRV and
Blackfin which makes me really curious and confused about what's going
on, since these are archs where FDPIC is actually in widespread use.
I've Cc'd their maintainers in case they know anything about the
issue.

> >Is there any way forward that allows fixing this bug (which
> >defeats the whole purpose of FDPIC) without breaking existing usage?
> 
> Maybe a kernel tuning option ?  (I am not familiar with kernel
> development so maybe this idea is a non-starter).

Actually I don't think anything would break. Right now the kernel
flips the meaning of the bit, so:

- Miscompiled/mislinked "FDPIC" programs which need to run with
  constant displacement actually don't get loaded with constant
  displacement by the kernel, so they're already not working.
  Presumably no such binaries exist since no one could run them
  without fixing this bug.

- Real FDPIC programs that want to run with variable displacement and
  text sharing are not getting it right now, but they _work_ anyway
  because, aside from massive resource inefficiency, constant
  displacement is just a special case of variable displacement. Thus,
  fixing the bug would just make them work as intended.

But I'm rather shocked that such an inconsistency could persist for so
long and doubting my own reading/analysis.

> >Or is there no existing usage to care about?
> 
> I could not say for sure, but I imagine that there must be at least
> some people who are using SH linux at the moment.

For SH, it only affects SH FDPIC users. Upstream gcc lacks support for
FDPIC on SH, so anyone using it is using the 2010 patch for gcc 4.5,
or some private gcc fork it's been applied to. It's not surprising at
all if this is broken, but it's hard to believe it's broken on the
other affected archs.

Rich

Re: SH FDPIC ABI spec/binutils and kernel conflict on flag definitions

[David Howells]

Rich Felker <dalias@libc.org> wrote:

> > I think that adopting the kernel's behaviour as correct would set a
> > dangerous precedent.  A published ABI should be followed, and if the
> > kernel does not implement it, then the kernel is wrong.

The kernel practice is that once an ABI is set, even if it's actually
implemented incorrectly, you cannot change it.

David

Re: SH FDPIC ABI spec/binutils and kernel conflict on flag definitions

[Rich Felker]

On Thu, Sep 10, 2015 at 04:45:30PM +0100, David Howells wrote:
> Rich Felker <dalias@libc.org> wrote:
> 
> > > I think that adopting the kernel's behaviour as correct would set a
> > > dangerous precedent.  A published ABI should be followed, and if the
> > > kernel does not implement it, then the kernel is wrong.
> 
> The kernel practice is that once an ABI is set, even if it's actually
> implemented incorrectly, you cannot change it.

Is that applicable even in places where fixing it won't break
anything? Do you see a problem in my analysis concluding that it
won't?

If we have to fix it on the binutils (& documentation) side, every
existing binary will remain wrong and only new binaries will get text
sharing.

On the other hand, the only existing way to produce a binary that both
(1) needs constant displacement, and (2) actually gets constant
displacement from the kernel at load time, is to manually edit the ELF
headers to flip the bit. So I really doubt any such binaries exist. Do
you have a reason to believe they do?

Rich

Re: SH FDPIC ABI spec/binutils and kernel conflict on flag definitions

[David Howells]

Rich Felker <dalias@libc.org> wrote:

> On the other hand, the only existing way to produce a binary that both
> (1) needs constant displacement, and (2) actually gets constant
> displacement from the kernel at load time, is to manually edit the ELF
> headers to flip the bit. So I really doubt any such binaries exist. Do
> you have a reason to believe they do?

Well, Fujitsu asked for it for FRV - I've no idea whether they have such
binaries still.

David

Re: SH FDPIC ABI spec/binutils and kernel conflict on flag definitions

[Rich Felker]

On Thu, Sep 10, 2015 at 04:53:35PM +0100, David Howells wrote:
> Rich Felker <dalias@libc.org> wrote:
> 
> > On the other hand, the only existing way to produce a binary that both
> > (1) needs constant displacement, and (2) actually gets constant
> > displacement from the kernel at load time, is to manually edit the ELF
> > headers to flip the bit. So I really doubt any such binaries exist. Do
> > you have a reason to believe they do?
> 
> Well, Fujitsu asked for it for FRV - I've no idea whether they have such
> binaries still.

OK. Can we get feedback from anyone who's actually using this code
now? I don't see how the current situation is at all acceptable for
anyone using it, but maybe I'm missing something. It seems programs
built as FDPIC are going through all the ABI cost for FDPIC (function
descriptors, restricted relative addressing) for absolutely no gain
because the kernel just loads them like plain non-FDPIC ELF files...

Rich

Re: SH FDPIC ABI spec/binutils and kernel conflict on flag definitions

[Rich Felker]

On Thu, Sep 10, 2015 at 12:01:49PM -0400, Rich Felker wrote:
> On Thu, Sep 10, 2015 at 04:53:35PM +0100, David Howells wrote:
> > Rich Felker <dalias@libc.org> wrote:
> > 
> > > On the other hand, the only existing way to produce a binary that both
> > > (1) needs constant displacement, and (2) actually gets constant
> > > displacement from the kernel at load time, is to manually edit the ELF
> > > headers to flip the bit. So I really doubt any such binaries exist. Do
> > > you have a reason to believe they do?
> > 
> > Well, Fujitsu asked for it for FRV - I've no idea whether they have such
> > binaries still.
> 
> OK. Can we get feedback from anyone who's actually using this code
> now? I don't see how the current situation is at all acceptable for
> anyone using it, but maybe I'm missing something. It seems programs
> built as FDPIC are going through all the ABI cost for FDPIC (function
> descriptors, restricted relative addressing) for absolutely no gain
> because the kernel just loads them like plain non-FDPIC ELF files...

I've now gotten gcc and my SH-FDPIC port of musl far enough along to
test on a real kernel/hardware, and I can confirm that the kernel's
interpretation of the bit is backwards, at least on SH. Since the code
is the same for all the other archs with FDPIC I think it's safe to
assume they're all broken. Patching the kernel to ignore the bit
yields shared text, as expected.

Rich

Re: SH FDPIC ABI spec/binutils and kernel conflict on flag definitions

[Rich Felker]

On Thu, Sep 10, 2015 at 04:53:35PM +0100, David Howells wrote:
> Rich Felker <dalias@libc.org> wrote:
> 
> > On the other hand, the only existing way to produce a binary that both
> > (1) needs constant displacement, and (2) actually gets constant
> > displacement from the kernel at load time, is to manually edit the ELF
> > headers to flip the bit. So I really doubt any such binaries exist. Do
> > you have a reason to believe they do?
> 
> Well, Fujitsu asked for it for FRV - I've no idea whether they have such
> binaries still.

OK, I've solved part of the mystery: on FRV and Blackfin, binutils
matches the kernel behavior and conflicts with the (effectively wrong)
ABI documents. As can be seen at the following locations in the
source, EF_$ARCH_PIC is cleared by default and set when there is a
cross-segment relocation that forces constant displacement:

Blackfin:
https://sourceware.org/git/?p=binutils-gdb.git;a=blob;f¿d/elf32-bfin.c;h\x152134ee7b9b445d96818fcab2350ffd11795897;hb=HEAD#l3140
https://sourceware.org/git/?p=binutils-gdb.git;a=blob;f¿d/elf32-bfin.c;h\x152134ee7b9b445d96818fcab2350ffd11795897;hb=HEAD#l4978

FRV:
https://sourceware.org/git/?p=binutils-gdb.git;a=blob;f¿d/elf32-frv.c;hú12528b3d11ab9ed7a4d5d894f8b9c1a5e783a9;hb=HEAD#l3919
https://sourceware.org/git/?p=binutils-gdb.git;a=blob;f¿d/elf32-frv.c;hú12528b3d11ab9ed7a4d5d894f8b9c1a5e783a9;hb=HEAD#l6367

And SH does the opposite:
https://sourceware.org/git/?p=binutils-gdb.git;a=blob;f¿d/elf32-sh.c;h{8d7636de5fe4ce169eacbeb876ab7d741df798;hb=HEAD#l5499
https://sourceware.org/git/?p=binutils-gdb.git;a=blob;f¿d/elf32-sh.c;h{8d7636de5fe4ce169eacbeb876ab7d741df798;hb=HEAD#l6656

So I think for consistency with other FDPIC targets, and to avoid
changing kernel ABI, binutils should just be fixed to match the
Blackfin and FRV interpretation of EF_$ARCH_PIC on SH as well.

Ideally fixed versions of the ABI documents should also be produced.

Rich

Re: SH FDPIC ABI spec/binutils and kernel conflict on flag definitions

[Mike Frysinger]

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

On 14 Sep 2015 12:09, Rich Felker wrote:
> On Thu, Sep 10, 2015 at 04:53:35PM +0100, David Howells wrote:
> > Rich Felker <dalias@libc.org> wrote:
> > > On the other hand, the only existing way to produce a binary that both
> > > (1) needs constant displacement, and (2) actually gets constant
> > > displacement from the kernel at load time, is to manually edit the ELF
> > > headers to flip the bit. So I really doubt any such binaries exist. Do
> > > you have a reason to believe they do?
> > 
> > Well, Fujitsu asked for it for FRV - I've no idea whether they have such
> > binaries still.
> 
> OK, I've solved part of the mystery: on FRV and Blackfin, binutils
> matches the kernel behavior and conflicts with the (effectively wrong)
> ABI documents. As can be seen at the following locations in the
> source, EF_$ARCH_PIC is cleared by default and set when there is a
> cross-segment relocation that forces constant displacement:
> 
> Blackfin:
> https://sourceware.org/git/?p=binutils-gdb.git;a=blob;f=bfd/elf32-bfin.c;h=152134ee7b9b445d96818fcab2350ffd11795897;hb=HEAD#l3140
> https://sourceware.org/git/?p=binutils-gdb.git;a=blob;f=bfd/elf32-bfin.c;h=152134ee7b9b445d96818fcab2350ffd11795897;hb=HEAD#l4978

it's a bit more complicated than that.  only one place does Blackfin
permit setting of EF_BFIN_PIC:
https://sourceware.org/git/?p=binutils-gdb.git;a=blob;f=bfd/elf32-bfin.c;h=152134ee7b9b445d96818fcab2350ffd11795897;hb=HEAD#l3140

and if you look before that, it has:
  if (!silence_segment_error && bfd_link_pic (info))
    return FALSE;

and those are defined as:
  int silence_segment_error = !bfd_link_pic (info);
  #define bfd_link_pic(info)  (bfd_link_dll (info) || bfd_link_pie (info))
  #define bfd_link_pie(info)  ((info)->type == type_pie)

all FDPIC ELFs must be PIE which means it's not possible to create a
Blackfin FDPIC ELF with EF_BFIN_PIC set.

off the top of my head, i don't recall seeing EF_BFIN_PIC being set
in Blackfin FDPIC ELFs.  it would show up when generating some FLAT
code w/-fpic, but that doesn't matter here.

> FRV:
> https://sourceware.org/git/?p=binutils-gdb.git;a=blob;f=bfd/elf32-frv.c;h=fa12528b3d11ab9ed7a4d5d894f8b9c1a5e783a9;hb=HEAD#l3919
> https://sourceware.org/git/?p=binutils-gdb.git;a=blob;f=bfd/elf32-frv.c;h=fa12528b3d11ab9ed7a4d5d894f8b9c1a5e783a9;hb=HEAD#l6367

the Blackfin code was copied from FRV, and the codepath i noted above
is the same for FRV.
-mike

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]