touch-packages team mailing list archive

[Adam Conrad <adconrad@xxxxxxx>]

Fixed packages in the queue and waiting approval for utopic and trusty.

** Description changed:

+ [ SRU Justification ]
+ Executing 32-bit arm binaries as user fails on arm64.  Turns out, this is bad.
+ 
+ [ Test Case ]
+ Grab a 32-bit binary (either multiarch via armhf, or compile a quick static hello) and try to run it.  Also, check /proc/sys/vm/mmap_min_addr is set to 32k instead of 64k after boot.
+ 
+ [ Regression Potential ]
+ Shouldn't be any issue with 4k pagesize kernels, and this was already the default on 32-bit ARM for the same reasons.  It could, potentially, mean that the zero page is no longer entirely protected from mmap when running a 64k pagesize kernel, however we don't currently ship such a kernel, preferring instead to have 32-bit compatibility.
+ 
+ [ Original Bug Report ]
  Executing 32-bit arm binaries as user fails on arm64:
  
  # file hello
  hello: ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV),
  statically linked, for GNU/Linux 2.6.32,
  BuildID[sha1]=c37a3b366d645eee600963a535370fa0bad9b2c0, not stripped
  # ./hello
  hello world
  # su - linaro
  $ /root/hello
  Segmentation fault
  
  Root cause was identified to /etc/sysctl.d/10-zeropage.conf, which is
  set on arm64 to 65536. To run legacy binaries, this should be set to
  32768 like on armhf anr armel.
  
  Reference discussion:
  
  http://lists.infradead.org/pipermail/linux-arm-
  kernel/2015-January/320454.html
  
  Affects trusty, utopic and vivid

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

Title:
  default mmap_min_addr for arm64 prevents running arm32 applications

Status in procps package in Ubuntu:
  Fix Released
Status in procps source package in Trusty:
  New
Status in procps source package in Utopic:
  New

Bug description:
  [ SRU Justification ]
  Executing 32-bit arm binaries as user fails on arm64.  Turns out, this is bad.

  [ Test Case ]
  Grab a 32-bit binary (either multiarch via armhf, or compile a quick static hello) and try to run it.  Also, check /proc/sys/vm/mmap_min_addr is set to 32k instead of 64k after boot.

  [ Regression Potential ]
  Shouldn't be any issue with 4k pagesize kernels, and this was already the default on 32-bit ARM for the same reasons.  It could, potentially, mean that the zero page is no longer entirely protected from mmap when running a 64k pagesize kernel, however we don't currently ship such a kernel, preferring instead to have 32-bit compatibility.

  [ Original Bug Report ]
  Executing 32-bit arm binaries as user fails on arm64:

  # file hello
  hello: ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV),
  statically linked, for GNU/Linux 2.6.32,
  BuildID[sha1]=c37a3b366d645eee600963a535370fa0bad9b2c0, not stripped
  # ./hello
  hello world
  # su - linaro
  $ /root/hello
  Segmentation fault

  Root cause was identified to /etc/sysctl.d/10-zeropage.conf, which is
  set on arm64 to 65536. To run legacy binaries, this should be set to
  32768 like on armhf anr armel.

  Reference discussion:

  http://lists.infradead.org/pipermail/linux-arm-
  kernel/2015-January/320454.html

  Affects trusty, utopic and vivid

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