Public bug reported:

On 20.04 (qemu 4.2) the binaries built for qemu-user-static -
specifically in the case I've hit /usr/bin/qemu-aarch64-static - are
completely static executables.

The same binaries from a qemu 5.x build are not. Although they don't
link to other shared libraries they are dynamically linked to glibc and
therefore require the same version of the glibc shared libraries at
runtime. This breaks many uses in foreign architecture chroots; in my
case an aarch64 being built with debootstrap:

On focal:

$ file /usr/bin/qemu-aarch64-static
/usr/bin/qemu-aarch64-static: ELF 64-bit LSB executable, x86-64, version 1 
(GNU/Linux), statically linked, 
BuildID[sha1]=abad039a2cfc5bc87215554230a572b085fbc37a, for GNU/Linux 3.2.0, 
with debug_info, not stripped

$ dpkg -S /usr/bin/qemu-aarch64-static
qemu-user-static: /usr/bin/qemu-aarch64-static

$ apt list qemu-user-static
qemu-user-static/focal-updates,focal-security,now 1:4.2-3ubuntu6.10 amd64 
[installed]

But recent builds of 5.2 are not; for example from hirsute (qemu-user-
static_5.2+dfsg-2ubuntu1_amd64.deb)

$ file /tmp/qemu-aarch64-static
/tmp/qemu-aarch64-static: ELF 64-bit LSB shared object, x86-64, version 1 
(GNU/Linux), dynamically linked, 
BuildID[sha1]=91fda2fa08f46d1bb6d19b6f72a4819a7c20fd7e, for GNU/Linux 3.2.0, 
stripped

I hit this whilst trying to track down another bug and building upstream
git HEAD on 20.04 with:

$ ../../qemu/configure --disable-system --enable-linux-user --static 
--target-list=aarch64-linux-user
$ make
$ file qemu-aarch64
qemu-aarch64: ELF 64-bit LSB shared object, x86-64, version 1 (GNU/Linux), 
dynamically linked, BuildID[sha1]=546ba11f0de940f7f3cbfaffae3c2bb54b683386, for 
GNU/Linux 3.2.0, with debug_info, not stripped

It looks like changes to the qemu build system are responsible. I asked
on OFTC #qemu and at that time no-one was particularly aware of the
significance/difference.

Looking at the configure output summary between the focal and
hirsute/upstream builds I noticed that there is no longer a separate
summary for LDFLAGS - it now only reports QEMU_LDFLAGS.

That seems significant since focal passed "-static" with LDFLAGS not
QEMU_LDFLAGS:

LDFLAGS           -Wl,--warn-common -Wl,-z,relro -Wl,-z,now -pie -m64 -g  
-Wl,-Bsymbolic-functions -Wl,-z,relro -Wl,--as-needed
QEMU_LDFLAGS

whereas hirsute shows:

QEMU_LDFLAGS: -Wl,--warn-common -Wl,-z,relro -Wl,-z,now -m64  -g -O2
-fdebug-prefix-map=/<<BUILDDIR>>/qemu-5.2+dfsg=. -fstack-protector-
strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2
-Wl,-Bsymbolic-functions -Wl,-z,relro -Wl,--as-needed -fstack-protector-
strong

I've seen mention in qemu commit messages of the meson build system
changes causing issues around passing of linker flags but it needs
someone familiar with the project and build system to figure this out.

** Affects: qemu (Ubuntu)
     Importance: Undecided
         Status: New

** Description changed:

  On 20.04 (qemu 4.2) the binaries built for qemu-user-static -
  specifically in the case I've hit /usr/bin/qemu-aarch64-static - are
- completely static executables. Although they don't link to other shared
- libraries they are dynamically linked to glibc and therefore require the
- same version of the glibc shared libraries at runtime. This breaks many
- uses in foreign architecture chroots; in my case an aarch64 being built
- with debootstrap:
+ completely static executables.
+ 
+ The same binaries from a qemu 5.x build are not. Although they don't
+ link to other shared libraries they are dynamically linked to glibc and
+ therefore require the same version of the glibc shared libraries at
+ runtime. This breaks many uses in foreign architecture chroots; in my
+ case an aarch64 being built with debootstrap:
+ 
+ On focal:
  
  $ file /usr/bin/qemu-aarch64-static
  /usr/bin/qemu-aarch64-static: ELF 64-bit LSB executable, x86-64, version 1 
(GNU/Linux), statically linked, 
BuildID[sha1]=abad039a2cfc5bc87215554230a572b085fbc37a, for GNU/Linux 3.2.0, 
with debug_info, not stripped
  
  $ dpkg -S /usr/bin/qemu-aarch64-static
  qemu-user-static: /usr/bin/qemu-aarch64-static
  
  $ apt list qemu-user-static
  qemu-user-static/focal-updates,focal-security,now 1:4.2-3ubuntu6.10 amd64 
[installed]
  
+ But recent builds of 5.2 are not; for example from hirsute (qemu-user-
+ static_5.2+dfsg-2ubuntu1_amd64.deb)
  
- But recent builds of 5.2 are not; for example from hirsute 
(qemu-user-static_5.2+dfsg-2ubuntu1_amd64.deb)
- 
- $ file /tmp/qemu-aarch64-static 
+ $ file /tmp/qemu-aarch64-static
  /tmp/qemu-aarch64-static: ELF 64-bit LSB shared object, x86-64, version 1 
(GNU/Linux), dynamically linked, 
BuildID[sha1]=91fda2fa08f46d1bb6d19b6f72a4819a7c20fd7e, for GNU/Linux 3.2.0, 
stripped
  
  I hit this whilst trying to track down another bug and building upstream
  git HEAD on 20.04 with:
  
  $ ../../qemu/configure --disable-system --enable-linux-user --static 
--target-list=aarch64-linux-user
  $ make
- $ file qemu-aarch64 
+ $ file qemu-aarch64
  qemu-aarch64: ELF 64-bit LSB shared object, x86-64, version 1 (GNU/Linux), 
dynamically linked, BuildID[sha1]=546ba11f0de940f7f3cbfaffae3c2bb54b683386, for 
GNU/Linux 3.2.0, with debug_info, not stripped
  
  It looks like changes to the qemu build system are responsible. I asked
  on OFTC #qemu and at that time no-one was particularly aware of the
  significance/difference.
  
  Looking at the configure output summary between the focal and
  hirsute/upstream builds I noticed that there is no longer a separate
  summary for LDFLAGS - it now only reports QEMU_LDFLAGS.
  
  That seems significant since focal passed "-static" with LDFLAGS not
  QEMU_LDFLAGS:
  
  LDFLAGS           -Wl,--warn-common -Wl,-z,relro -Wl,-z,now -pie -m64 -g  
-Wl,-Bsymbolic-functions -Wl,-z,relro -Wl,--as-needed
  QEMU_LDFLAGS
  
  whereas hirsute shows:
  
  QEMU_LDFLAGS: -Wl,--warn-common -Wl,-z,relro -Wl,-z,now -m64  -g -O2
  -fdebug-prefix-map=/<<BUILDDIR>>/qemu-5.2+dfsg=. -fstack-protector-
  strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2
  -Wl,-Bsymbolic-functions -Wl,-z,relro -Wl,--as-needed -fstack-protector-
  strong
  
  I've seen mention in qemu commit messages of the meson build system
  changes causing issues around passing of linker flags but it needs
  someone familiar with the project and build system to figure this out.

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1908331

Title:
  Regression: qemu-user-static binaries are dynamically linked

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

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

Reply via email to