← Back to team overview

touch-packages team mailing list archive

[Bug 1412553] Comment bridged from LTC Bugzilla

 

------- Comment From azanella@xxxxxxxxxx 2015-01-26 16:02 EDT-------
This is a comment from Alan Modra:

COMMONPAGESIZE in the linker should match kernel page size for two reasons:
- The linker optimisation that trades disk pages for memory pages is most
effective when they match.  If you're running a kernel that, say, uses 64k
pages, but your linker commonpagesize is 4k then your executables and
shared libraries will use up to 4k extra on disk but be ineffective in
saving memory pages.  Only 1 in 16 binaries will save a memory page.
Conversely, if your kernel used 4k pages but commonpagesize was 16k, then
you'd waste up to 16k on disk to make only a 4k saving in memory, ie. you'd
be wasting 12k of disk to no purpose.
- The linker -z relro layout also uses commonpagesize.  Some might say this
is a bug..  -z relro also increases executable size, both in memory and on
disk, in order to reduce the potential for an evil attacker to subvert a
binary, by making more of the binary read-only at startup.  Like the
disk/memory tradeoff, -z relro is ineffective if commonpagesize is
*smaller* than the actual kernel page size.  (The same 1 in n binaries,
where n is commonpagesize/kernelpagesize, will properly protect the last
page in the relro area.)  If commonpagesize is larger than the kernel page
size then -z relro works but wastes memory.

So that's the WHY.  Sorry it isn't complete as I don't know off the top of
my head what page size the Ubuntu kernels use.

Note that from the -z relro view, we have other things that need fixing in
the linker but I wouldn't recommend backporting just yet.  The patches I've
committed upstream 3e2b0f31, 23283c1b, 5ad18f16, aren't too well tested and
are known to break some xlc compiled binaries.

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to binutils in Ubuntu.
https://bugs.launchpad.net/bugs/1412553

Title:
  RELRO not working on Ubuntu 14.04

Status in binutils package in Ubuntu:
  Fix Released
Status in binutils source package in Trusty:
  New

Bug description:
  RELRO (RELocation Read-Only) is security feature provided by the
  linker and implemented in conjunction with glibc to relocations
  sections that are used to resolve dynamically loaded functions read-
  only.

  The GLIBC side looks at the segments placement set by the linker and
  if they met some criteria regarding alignment, the are mprotect to be
  read-only.  More specifically, on GLIBC code:

  elf/dl-reloc.c:

  324 void internal_function
  325 _dl_protect_relro (struct link_map *l)
  326 {
  327   ElfW(Addr) start = ((l->l_addr + l->l_relro_addr)
  328                       & ~(GLRO(dl_pagesize) - 1));
  329   ElfW(Addr) end = ((l->l_addr + l->l_relro_addr + l->l_relro_size)
  330                     & ~(GLRO(dl_pagesize) - 1));
  331 
  332   if (start != end
  333       && __mprotect ((void *) start, end - start, PROT_READ) < 0)
  334     {
  335       static const char errstring[] = N_("\
  336 cannot apply additional memory protection after relocation");
  337       _dl_signal_error (errno, l->l_name, NULL, errstring);
  338     }
  339 }

  The problem is, if linker does not set the alignment correctly,
  'start' and 'end' will be equal and thus not protected. And this is
  happening on Ubuntu 14.04 due the fact its uses default binutils
  elf{32,64}-ppc.c ELF_COMMONPAGESIZE to align it to 4k instead of 64k.

  There is a recent patch on binutils-dev maillist [1] to change the
  default for 64k and Fedora rawhide already sets it [2] in its
  binutils.spec spec:

  # On ppc64 and aarch64, we might use 64KiB pages
  sed -i -e '/#define.*ELF_COMMONPAGESIZE/s/0x1000$/0x10000/' bfd/elf*ppc.c
  sed -i -e '/#define.*ELF_COMMONPAGESIZE/s/0x1000$/0x10000/' bfd/elf*aarch64.c

  Ubuntu for powerpc64le should do the same.

  [1] https://sourceware.org/ml/binutils/2014-12/msg00165.html
  [2] http://dl.fedoraproject.org/pub/fedora/linux/development/rawhide/source/SRPMS/b/binutils-2.24-29.fc22.src.rpm

  I tested and building a binutils with the ELF_COMMONPAGESIZE set to
  64k instead of default 4k and rebuilding GLIBC I see its relocation
  sections being correctly mprotected.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/binutils/+bug/1412553/+subscriptions