Re: [RFC] [MIPS] Enable non-executable PT_GNU_STACK support v2

Re: [RFC] [MIPS] Enable non-executable PT_GNU_STACK support v2

[Aaro Koskinen]

Hi,

On Thu, Aug 11, 2016 at 11:01:18PM +0200, Aurelien Jarno wrote:
> On 2016-02-05 10:38, Faraz Shahbazker wrote:
> > Bump!
> > 
> > Related patches for review:
> > * binutils: https://sourceware.org/ml/libc-alpha/2016-01/msg00567.html
> > * gcc :     https://gcc.gnu.org/ml/gcc-patches/2016-02/msg00444.html
> > 
> 
> It seems that the patches are present in the 2.27 binutils release,
> while they are not yet ready on the glibc side (I guess still waiting
> on the IFUNC patches).
> 
> This means that building binaries with -Wl,-z,noexecstack set the ABI
> version to 5 and we then have no way to execute them. Some configure
> scripts probe for the availability of this option and enable it
> automatically.

Would it be possible to revert (or provide option to disable) these
changes in binutils 2.28?

A.

Re: [RFC] [MIPS] Enable non-executable PT_GNU_STACK support v2

[Maciej W. Rozycki]

Hi,

On Thu, 22 Dec 2016, Aaro Koskinen wrote:

> On Thu, Aug 11, 2016 at 11:01:18PM +0200, Aurelien Jarno wrote:
> > On 2016-02-05 10:38, Faraz Shahbazker wrote:
> > > Bump!
> > > 
> > > Related patches for review:
> > > * binutils: https://sourceware.org/ml/libc-alpha/2016-01/msg00567.html
> > > * gcc :     https://gcc.gnu.org/ml/gcc-patches/2016-02/msg00444.html
> > > 
> > 
> > It seems that the patches are present in the 2.27 binutils release,
> > while they are not yet ready on the glibc side (I guess still waiting
> > on the IFUNC patches).
> > 
> > This means that building binaries with -Wl,-z,noexecstack set the ABI
> > version to 5 and we then have no way to execute them. Some configure
> > scripts probe for the availability of this option and enable it
> > automatically.
> 
> Would it be possible to revert (or provide option to disable) these
> changes in binutils 2.28?

 Making PT_GNU_STACK executables stop working with legacy glibc which 
does not support the feature required is IIUC the whole point of the 
binutils change, so it serves its purpose AFAICT.  I can revert the 
change, but before I do it can someone please tell me why can't MIPS 
support for PT_GNU_STACK be simply pushed to glibc instead?  And what's 
the relevance of the IFUNC feature here (which will now use ABI version 
6, the next available one) -- is there a functional dependency between 
the glibc side of these two features?

  Maciej

Re: [RFC] [MIPS] Enable non-executable PT_GNU_STACK support v2

[Joseph Myers]

On Thu, 22 Dec 2016, Maciej W. Rozycki wrote:

>  Making PT_GNU_STACK executables stop working with legacy glibc which 
> does not support the feature required is IIUC the whole point of the 
> binutils change, so it serves its purpose AFAICT.  I can revert the 
> change, but before I do it can someone please tell me why can't MIPS 
> support for PT_GNU_STACK be simply pushed to glibc instead?  And what's 
> the relevance of the IFUNC feature here (which will now use ABI version 
> 6, the next available one) -- is there a functional dependency between 
> the glibc side of these two features?

I thought 4 was reserved for IFUNC, meaning that support for 5 implied 
support for IFUNC (because a simple comparison is all that's available to 
tell whether glibc supports the features required by an executable / 
shared library; it's a single ABI version number, not a bitmask of 
features used) and so the ordering was forced.  Certainly the patch here 
lists IFUNC before MIPS_GNU_STACK, and I don't think the libc-abis system 
supports gaps in the numbering (you'd need to put in a dummy name if 4 is 
now to be unused, but then the dummy name would be visible when you run 
libc.so.6, which it shouldn't be).

Has a non-RFC patch posting for glibc for this feature been made?  If it's 
to get in glibc someone will need to post a patch tested against current 
glibc - with the architecture-independent pieces posted separately from 
the MIPS-specific pieces, please, as they are likely to be reviewed 
separately, making sure to include self-contained rationale and pointers 
to any relevant ABIs, information about kernel, GCC, binutils support, 
etc. (I'd suggest updating the comment on the XFAIL in 
sysdeps/unix/sysv/linux/mips/Makefile to give concrete information about 
the specific versions of GCC and binutils needed for the test to pass / 
kernel version needed for no-exec stack support to work properly - I mean 
upstream mainline versions, any references to uncommitted or non-mainline 
patches need to be clear about their status).  Even then, it seems 
unlikely you'll get review in time for 2.25, i.e. by 31 December (and you 
may need to keep pinging weekly); I don't know how many dynamic linker 
experts we have to review the design of the architecture-independent 
pieces.

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: [RFC] [MIPS] Enable non-executable PT_GNU_STACK support v2

[Joseph Myers]

On Thu, 22 Dec 2016, Joseph Myers wrote:

> I thought 4 was reserved for IFUNC, meaning that support for 5 implied 
> support for IFUNC (because a simple comparison is all that's available to 
> tell whether glibc supports the features required by an executable / 
> shared library; it's a single ABI version number, not a bitmask of 
> features used) and so the ordering was forced.  Certainly the patch here 
> lists IFUNC before MIPS_GNU_STACK, and I don't think the libc-abis system 
> supports gaps in the numbering (you'd need to put in a dummy name if 4 is 
> now to be unused, but then the dummy name would be visible when you run 
> libc.so.6, which it shouldn't be).

The natural way to address that issue, incidentally, would be to reassign 
number 4 to MIPS_GNU_STACK and say that IFUNC will get number 5 when 
ready.  (All the other comments about patch proposals that are explicitly 
for review not RFC, with rationale, architecture-independent pieces split 
out etc., still apply.)

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: [RFC] [MIPS] Enable non-executable PT_GNU_STACK support v2

[Maciej W. Rozycki]

On Thu, 22 Dec 2016, Joseph Myers wrote:

> > I thought 4 was reserved for IFUNC, meaning that support for 5 implied 
> > support for IFUNC (because a simple comparison is all that's available to 
> > tell whether glibc supports the features required by an executable / 
> > shared library; it's a single ABI version number, not a bitmask of 
> > features used) and so the ordering was forced.  Certainly the patch here 
> > lists IFUNC before MIPS_GNU_STACK, and I don't think the libc-abis system 
> > supports gaps in the numbering (you'd need to put in a dummy name if 4 is 
> > now to be unused, but then the dummy name would be visible when you run 
> > libc.so.6, which it shouldn't be).
> 
> The natural way to address that issue, incidentally, would be to reassign 
> number 4 to MIPS_GNU_STACK and say that IFUNC will get number 5 when 
> ready.  (All the other comments about patch proposals that are explicitly 
> for review not RFC, with rationale, architecture-independent pieces split 
> out etc., still apply.)

 Unfortunately binutils 2.27 have been released which already set ABI 
version to 5 despite that they do not support IFUNC.  So we cannot 
retroactively make version 5 imply IFUNC support, and consequently we 
cannot make version 4 imply IFUNC support either, as we work under the 
assumption that any given ABI version supports all the previous 
(lower-numbered) ABI versions' features.

 We can make version 4 imply MIPS_GNU_STACK because it will not break the 
said assumption, and I suppose it may help with chosing reasonable ABI 
names for versions 4 and 5 if we cannot support gaps (why?).  However 
IFUNC will have to use version 6 or higher.

 Have I missed anything?

 Regrettably I haven't realised I need to veto the binutils change before 
it was upstreamed, or at least back it out before 2.27 went out; sorry 
about that.

  Maciej

Re: [RFC] [MIPS] Enable non-executable PT_GNU_STACK support v2

[Joseph Myers]

On Thu, 22 Dec 2016, Maciej W. Rozycki wrote:

>  Unfortunately binutils 2.27 have been released which already set ABI 
> version to 5 despite that they do not support IFUNC.  So we cannot 
> retroactively make version 5 imply IFUNC support, and consequently we 
> cannot make version 4 imply IFUNC support either, as we work under the 
> assumption that any given ABI version supports all the previous 
> (lower-numbered) ABI versions' features.

It's only if a version was released in glibc that you can't reassign it.  
I don't see why you can't change binutils to use version 4 for GNU_STACK 
(and then 5 for IFUNC), probably including on 2.27 branch - binaries built 
to use version 5 for GNU_STACK just won't work with glibc until it gets 
IFUNC support.  The relevant rule is: glibc doesn't claim to support a 
version unless it supports all ABIs <= that version (that is, all ABIs 
used by binaries that give a version <= that version).

It's OK for binaries to specify an ABI version higher than they require 
(which would, effectively, be the case for binaries built now that use 
version 5 for GNU_STACK - version 5 meaning, under the reassigned numbers, 
that you need a glibc supporting all of MIPS_PLT, UNIQUE, MIPS_O32_FP64, 
GNU_STACK and IFUNC - which is a stricter requirement than necessary, but 
it's OK for binaries to specify stricter requirements than necessary).

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: [RFC] [MIPS] Enable non-executable PT_GNU_STACK support v2

[Maciej W. Rozycki]

On Thu, 22 Dec 2016, Joseph Myers wrote:

> It's only if a version was released in glibc that you can't reassign it.  
> I don't see why you can't change binutils to use version 4 for GNU_STACK 
> (and then 5 for IFUNC), probably including on 2.27 branch - binaries built 
> to use version 5 for GNU_STACK just won't work with glibc until it gets 
> IFUNC support.  The relevant rule is: glibc doesn't claim to support a 
> version unless it supports all ABIs <= that version (that is, all ABIs 
> used by binaries that give a version <= that version).
> 
> It's OK for binaries to specify an ABI version higher than they require 
> (which would, effectively, be the case for binaries built now that use 
> version 5 for GNU_STACK - version 5 meaning, under the reassigned numbers, 
> that you need a glibc supporting all of MIPS_PLT, UNIQUE, MIPS_O32_FP64, 
> GNU_STACK and IFUNC - which is a stricter requirement than necessary, but 
> it's OK for binaries to specify stricter requirements than necessary).

 OK, this makes sense to me, thanks for the clarification.

 Change reverted now then with commit 4d4f40e041ce ("MIPS/BFD: Remove 
EI_ABIVERSION 5 allocation for PT_GNU_STACK support") and backported to 
2.28 and 2.27 branches.

 Happy festive season, everyone!

  Maciej

Re: [RFC] [MIPS] Enable non-executable PT_GNU_STACK support v2

[Aaro Koskinen]

Hi,

On Thu, Dec 22, 2016 at 12:52:41AM +0000, Maciej W. Rozycki wrote:
> On Thu, 22 Dec 2016, Aaro Koskinen wrote:
> > On Thu, Aug 11, 2016 at 11:01:18PM +0200, Aurelien Jarno wrote:
> > > On 2016-02-05 10:38, Faraz Shahbazker wrote:
> > > > Bump!
> > > > 
> > > > Related patches for review:
> > > > * binutils: https://sourceware.org/ml/libc-alpha/2016-01/msg00567.html
> > > > * gcc :     https://gcc.gnu.org/ml/gcc-patches/2016-02/msg00444.html
> > > > 
> > > 
> > > It seems that the patches are present in the 2.27 binutils release,
> > > while they are not yet ready on the glibc side (I guess still waiting
> > > on the IFUNC patches).
> > > 
> > > This means that building binaries with -Wl,-z,noexecstack set the ABI
> > > version to 5 and we then have no way to execute them. Some configure
> > > scripts probe for the availability of this option and enable it
> > > automatically.
> > 
> > Would it be possible to revert (or provide option to disable) these
> > changes in binutils 2.28?
> 
>  Making PT_GNU_STACK executables stop working with legacy glibc which 
> does not support the feature required is IIUC the whole point of the 
> binutils change, so it serves its purpose AFAICT.

Maybe, but today only "legacy glibc" exists and people have no way
of knowing or preparing for that when taking new binutils into use. I
don't think it's good a practice to make a release that depends on some
imaginary future version of some other software component. At least it's
not very pragmatic.

A.