| 2020-12-16 00:52:58 |
TJ |
bug |
|
|
added bug |
| 2020-12-16 00:54:50 |
TJ |
description |
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:
$ 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. |
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. |
|
| 2020-12-16 01:43:22 |
TJ |
description |
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. |
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 -m64 -static -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 -static-pie -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
(notice it is -static-pie not -static now)
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. |
|
| 2020-12-16 09:04:13 |
Christian Ehrhardt |
qemu (Ubuntu): status |
New |
Triaged |
|
| 2020-12-16 09:04:18 |
Christian Ehrhardt |
bug |
|
|
added subscriber Christian Ehrhardt |
| 2020-12-16 09:04:24 |
Christian Ehrhardt |
bug |
|
|
added subscriber Ubuntu Server |
| 2020-12-16 09:04:31 |
Christian Ehrhardt |
tags |
|
server-next |
|
| 2020-12-16 09:04:37 |
Christian Ehrhardt |
nominated for series |
|
Ubuntu Groovy |
|
| 2020-12-16 09:04:37 |
Christian Ehrhardt |
bug task added |
|
qemu (Ubuntu Groovy) |
|
| 2021-01-05 07:21:55 |
Christian Ehrhardt |
qemu (Ubuntu): importance |
Undecided |
High |
|
| 2021-01-05 07:21:56 |
Christian Ehrhardt |
qemu (Ubuntu Groovy): importance |
Undecided |
Medium |
|
| 2021-01-05 14:48:13 |
Launchpad Janitor |
merge proposal linked |
|
https://code.launchpad.net/~paelzer/ubuntu/+source/qemu/+git/qemu/+merge/395786 |
|
| 2021-01-06 08:52:59 |
Christian Ehrhardt |
description |
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 -m64 -static -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 -static-pie -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
(notice it is -static-pie not -static now)
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. |
[ Impact ]
* An upstream change [1] had undesired impact of making qemu-user-static
no more fully static. In some cases e.g. cross arch debootstrapping
that breaks the use case.
* The root cause is the use of ld with an unsupported pie related flag.
We have fixed this upstream and this backports that change.
[Test Case]
* $ file $(dpkg -L qemu-user-static | grep bin\/qemu-.*-static)
Should show "statically linked", but not "dynamically linked" (bad case)
[Where problems could occur]
* I can't think of an immediate expected regression that comes to mind,
but the following at least limits the area to look for issues.
The change it limited to qemu-user-static. Therefore impacts would be
seen there but not in e.g. system emulation (other binaries, those
didn't change except for being rebuilt).
Also the new behavior matches what we had pre-groovy and therfore what
users expect.
[Other Info]
* n/a
[1]: https://git.qemu.org/?p=qemu.git;a=commit;h=127814629b32d5e0de2873d742e08cb9bd412af7
---
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 -m64 -static -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 -static-pie -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
(notice it is -static-pie not -static now)
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. |
|
| 2021-01-08 13:48:22 |
Timo Aaltonen |
qemu (Ubuntu Groovy): status |
New |
Fix Committed |
|
| 2021-01-08 13:48:24 |
Timo Aaltonen |
bug |
|
|
added subscriber Ubuntu Stable Release Updates Team |
| 2021-01-08 13:48:26 |
Timo Aaltonen |
bug |
|
|
added subscriber SRU Verification |
| 2021-01-08 13:48:29 |
Timo Aaltonen |
tags |
server-next |
server-next verification-needed verification-needed-groovy |
|
| 2021-01-11 09:48:57 |
Christian Ehrhardt |
tags |
server-next verification-needed verification-needed-groovy |
server-next verification-done verification-done-groovy |
|
| 2021-01-11 11:37:54 |
Launchpad Janitor |
qemu (Ubuntu): status |
Triaged |
Fix Released |
|
| 2021-01-18 17:06:50 |
Launchpad Janitor |
qemu (Ubuntu Groovy): status |
Fix Committed |
Fix Released |
|
| 2021-01-18 17:07:05 |
Łukasz Zemczak |
removed subscriber Ubuntu Stable Release Updates Team |
|
|
|
| 2023-11-27 20:52:24 |
Athos Ribeiro |
tags |
server-next verification-done verification-done-groovy |
server-next server-triage-discuss verification-done verification-done-groovy |
|
