Hello bugproxy, or anyone else affected,

Accepted binutils into trusty-proposed. The package will build now and
be available at
https://launchpad.net/ubuntu/+source/binutils/2.24-5ubuntu13 in a few
hours, and then in the -proposed repository.

Please help us by testing this new package.  See
https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to
enable and use -proposed.  Your feedback will aid us getting this update
out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug,
mentioning the version of the package you tested, and change the tag
from verification-needed to verification-done. If it does not fix the
bug for you, please add a comment stating that, and change the tag to
verification-failed.  In either case, details of your testing will help
us make a better decision.

Further information regarding the verification process can be found at
https://wiki.ubuntu.com/QATeam/PerformingSRUVerification .  Thank you in
advance!

** Changed in: binutils (Ubuntu Trusty)
       Status: New => Fix Committed

** Tags added: verification-needed

-- 
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:
  Fix Committed

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

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to     : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp

Reply via email to