Bug 427890 – binutils/glibc: status of custom PaX patches

• Product: Gentoo Linux
• Status: RESOLVED OBSOLETE

[Description Anthony Basile 2012-07-24 14:31:00 UTC]

BACKGROUND:  PaX markings are used by a PaX enabled kernel (aka hardened kernel) to selectively enforce/not enforce various memory constraints on running processes based on flags found either 1) in bytes 14 & 15 of ehdr.e_ident[] in the elf binary header, 2) in the elf program header marked type PT_PAX and 3) in the extended attribute field with name user.pax.flags if the filesystem has xattr support.  There are advantages and disadvantages to each approach.  However, because of bug #387459, using the elf header is broken and deprecated.  It is in the process of being removed completely from Gentoo.

See also: http://archives.gentoo.org/gentoo-dev/msg_4fc5b8e2bdd09f7394b23b44d944c4d7.xml

PROPOSAL: It is possible on properly configured systems, ie ones in which the necessary file systems support extended attributes (possible since linux-3.x), to move the PaX markings completely to the extended attributes and not ever mangle the elf binaries either 1) by having binutils include a PT_PAX phdr when constructing an elf, or 2) using paxctl to add one or convert a PT_NULL to PT_PAX.  Therefore we could make binutils patch 63 contingent on a flag, like !xtpax which is the flag representing support for xattr pax markings.

This has the advantage of making Gentoo ELF binaries more in line with binaries built on other linux distros and imported to Gentoo, eg java, skype, etc.

See also: http://archives.gentoo.org/gentoo-dev/msg_c1c232bfceb33692b1c8fb3028fae9d1.xml

The disadvantage is that there is a greater demand for proper user configuration of the kernel and userland.

Reproducible: Always

[Comment 1 SpanKY 2012-07-24 15:32:18 UTC]

we haven't touched Elf_Ehdr in a long time -- we only automatically add PT_PAX.  i don't see the point of making the patch optional today.

[Comment 2 Anthony Basile 2012-07-24 16:34:57 UTC]

(In reply to comment #1)
> we haven't touched Elf_Ehdr in a long time

Not toolchain, but others have vi chpax to deal with issue of self-checking elfs which break when one tries to add a PT_PAX phdr

>  i don't see the point of making the patch optional today.

Agreed.  This is long term.

[Comment 3 SpanKY 2012-07-24 17:37:31 UTC]

(In reply to comment #2)

in terms of local testing, you should be able to do this already by using setting EPATCH_EXCLUDE in your /etc/portage/ per-package env.  i'm not keen on adding a USE flag here since there's a large number of binutils ebuilds.

[Comment 4 Anthony Basile 2012-07-24 22:51:31 UTC]

(In reply to comment #3)
> (In reply to comment #2)
> 
> in terms of local testing, you should be able to do this already by using
> setting EPATCH_EXCLUDE in your /etc/portage/ per-package env.  i'm not keen
> on adding a USE flag here since there's a large number of binutils ebuilds.

Yeah, I like that.  As much as I hate documenting I know I'm going to have to and that's what I'm going to suggest.

[Comment 5 SpanKY 2012-08-12 02:35:43 UTC]

hmm, is there any reason to keep carrying this patch ?

http://sources.gentoo.org/gentoo/src/patchsets/glibc/2.16.0/3010_all_2.3.3_pre20040117-pt_pax.patch

nothing in our toolchain really requires it, and if the move is to stop using the ELF program headers, then we can go ahead and drop this patch.  any package out there that uses the define is most likely going to have a copy locally since most distros don't have it defined in their elf.h.

[Comment 6 SpanKY 2012-08-12 05:19:31 UTC]

hmm, and there's this guy:

http://sources.gentoo.org/gentoo/src/patchsets/glibc/2.16.0/3000_all_2.3.6-dl_execstack-PaX-support.patch

reading the documentation, it's only for ELFs that weren't compiled with PT_GNU_STACK which really only comes up with binary-only packages.  so if we dropped it today, it'd only affect those ...

[Comment 7 Anthony Basile 2012-08-12 12:35:33 UTC]

(In reply to comment #5)
> hmm, is there any reason to keep carrying this patch ?
> 
> http://sources.gentoo.org/gentoo/src/patchsets/glibc/2.16.0/3010_all_2.3.
> 3_pre20040117-pt_pax.patch
> 
> nothing in our toolchain really requires it, and if the move is to stop
> using the ELF program headers, then we can go ahead and drop this patch. 
> any package out there that uses the define is most likely going to have a
> copy locally since most distros don't have it defined in their elf.h.

The problem would only occur for users with systems that cannot support xattrs.  Executables that need pax markings different than the default and live on filesystems which do not support xattrs would break.

So we need to think about what scenarious might arrise where the users wants/needs to use a hardened kernel but cannot use a filesystem with xattrs.  I'm hard pressed to find such a case.

I'm leaning towards removing, but lets' see what others have to say.

[Comment 8 SpanKY 2012-08-12 14:37:23 UTC]

(In reply to comment #7)

well, it'd be an issue for legacy systems that don't have xattrs enabled, and attempt to run binary programs.  if xattrs are the long term goal, i'm fine pushing people in that direction.

[Comment 9 SpanKY 2012-08-18 03:32:25 UTC]

(In reply to comment #5)

i've dropped this change (to elf.h) from 2.16.0

[Comment 10 Anthony Basile 2012-08-18 22:03:01 UTC]

> i'm fine pushing people in that direction.

Okay and I'll get serious about documenting the migration, bug #431910.  Its pretty easy to migrate/work with xattr pax, but if a user doesn't know, they just don't know.  If we (ie "I") inform them, then pushing them in this direction should be relatively painless.

[Comment 11 PaX Team 2012-09-15 23:30:10 UTC]

(In reply to comment #6)
> hmm, and there's this guy:
> 
> http://sources.gentoo.org/gentoo/src/patchsets/glibc/2.16.0/3000_all_2.3.6-
> dl_execstack-PaX-support.patch
> 
> reading the documentation, it's only for ELFs that weren't compiled with
> PT_GNU_STACK which really only comes up with binary-only packages.  so if we
> dropped it today, it'd only affect those ...

this patch is needed for all the RWE GNU_STACK headers as well because PaX doesn't use this entirely broken concept to control runtime code generation (there's a glibc bug on this from around 2004 or so, you can dig it up by looking for me there ;).

[Comment 12 SpanKY 2015-08-13 07:48:06 UTC]

(In reply to PaX Team from comment #11)

that patch was dropped w/glibc-2.16 as the code in question was heavily rewritten

i don't see a bug in glibc's bugzilla where you commented/posted.  can you post the bug # here for tracking ?

that said, if the issue only comes up when GNU_STACK is RWE, then maybe we don't care ?  we already flag/complain/fail when such binaries are compiled.

[Comment 13 SpanKY 2015-08-13 07:50:38 UTC]

(In reply to SpanKY from comment #12)

nm, i see the newer discussion in our bug 431810 now

[Comment 14 Anthony Basile 2015-08-13 20:40:20 UTC]

@vapier.  We should be ready to drop the PaX patch in binutils 2.26.  The XATTR_PAX approach has matured and by the time 2.26 goes stable, there will have been plenty of time to catch any remaining problems.

[Comment 15 Andreas K. Hüttel 2017-12-09 21:43:50 UTC]

AFAIK there are no custom patches applied anymore. (Confirmed by zorry.)