The https://salsa.debian.org/qemu-team/qemu contains pre-built binaries.

./linux-user/ppc/vdso-64le.so
./linux-user/ppc/vdso-32.so
./linux-user/ppc/vdso-64.so
./linux-user/x86_64/vdso.so
./linux-user/hppa/vdso.so
./linux-user/loongarch64/vdso.so
./linux-user/s390x/vdso.so
./linux-user/i386/vdso.so
./linux-user/riscv/vdso-32.so
./linux-user/riscv/vdso-64.so
./linux-user/arm/vdso-le.so
./linux-user/arm/vdso-be32.so
./linux-user/arm/vdso-be8.so
./linux-user/aarch64/vdso-le.so
./linux-user/aarch64/vdso-be.so

Binaries should always be built from source.

Best regards

Heinrich

20.01.2025 23:22, Heinrich Schuchardt wrote:

Do you have a solution for this, which works on bookworm too?

Hint: there's no loong64 cross-compiler in bookworm.

Thanks,

/mjt

20.01.2025 23:22, Heinrich Schuchardt wrote:

Do you have a solution for this, which works on bookworm too?

Hint: there's no loong64 cross-compiler in bookworm.

Thanks,

/mjt

Hello Michael,

I can understand that a maintainer cares about keeping his package
buildable but system security is of even higher importance.

The xz package has demonstrated the security impact of including
binaries of unchecked origin.

Why do we ship *.so files for architectures that can be built from
source like qemu-9.2.0/linux-user/riscv/vdso-64.so?

Has the security team ever confirmed that shipping binaries in the QEMU
source is ok?

Best regards

Heinrich

Hello Michael,

I can understand that a maintainer cares about keeping his package
buildable but system security is of even higher importance.

The xz package has demonstrated the security impact of including
binaries of unchecked origin.

Why do we ship *.so files for architectures that can be built from
source like qemu-9.2.0/linux-user/riscv/vdso-64.so?

Has the security team ever confirmed that shipping binaries in the QEMU
source is ok?

Best regards

Heinrich

20.01.2025 23:49, Heinrich Schuchardt wrote:

I don't want to use different source for other systems.

Have you actually checked the build process before filing
this bug report?  Are you aware these binaries are *not*
used on debian trixie, but *are* used on ubuntu because
ubuntu does not have separate arch-all build?

What it has to do with the security team?

/mjt

20.01.2025 23:53, Michael Tokarev wrote:
qemu 9.2 source package, - exactly because these are not used
on debian (they're used in bookworm-backoprts only) but didn't
dropped these *because* of ubuntu who's using them.

/mjt

On Tue, 21 Jan 2025 00:09:33 +0300 Michael Tokarev <mjt@tls.msk.ru>
wrote:> Just so you know: I was about to drop these binaries in debian
So. With trixie is nearing its release, I'm reviewing this topic
once again.  Actually, these pre-built binaries aren't needed
(and aren't used) for trixie, because all the necessary cross-
compilers are available there.  But they're needed in ubuntu.
How can we handle this on ubuntu, so these binaries, once dropped
in debian, wont has to be resurrected on ubuntu?

I know very little about ubuntu build process.

Thanks,

/mjt

Pinging this issue again.  For me it's easy to just drop the pre-built
binaries from the debian source package.  The question is how to handle
this on ubuntu.

Thanks,

/mjt

Hi Michael and Heinrich,
sorry for missing this bug for so long, neither of the pings got to me
and I can't even find them in #debian-qemu now that I actively search
them :-/ Anyway - Sergio forwarded your ping to get my input on this.

First of all, this is all super old, and changed a bit over time each
time something failed.
No one of us is very deeply into the build or usage of these vdso
files. After all they are a performance optimization to speed up
execution with less syscall overhead. But for that they need to be per
target architecture.
Due to that you need all the cross compilers. Hence Michael said that
he no longer needs this for Debian, as there all the cross compilers
are available (as for Ubuntu). But Ubuntu is different in regard what
we can depend on - remember this is usually only touched when
breaking, last time it was Sergio who spotted a failure after the most
recent changes and for the time being none of us found a better
solution than adapting to keep them to break the dependency.

Here is an example list of related build dependencies with qualifiers
by the build profile:

debian/control-in:179: gcc-arm-linux-gnueabi
<!pkg.qemu.use-upstream-vdso>, libc6-dev-armel-cross
<!pkg.qemu.use-upstream-vdso>,
debian/control-in:180: gcc-hppa-linux-gnu
<!pkg.qemu.use-upstream-vdso>, libc6-dev-hppa-cross
<!pkg.qemu.use-upstream-vdso>,
debian/control-in:181: gcc-i686-linux-gnu
<!pkg.qemu.use-upstream-vdso>, libc6-dev-i386-cross
<!pkg.qemu.use-upstream-vdso>,
debian/control-in:182: gcc-loongarch64-linux-gnu
<!pkg.qemu.use-upstream-vdso>, libc6-dev-loong64-cross
<!pkg.qemu.use-upstream-vdso>,
debian/control-in:183: gcc-powerpc64-linux-gnu
<!pkg.qemu.use-upstream-vdso>, libc6-dev-ppc64-cross
<!pkg.qemu.use-upstream-vdso>,
debian/control-in:184: gcc-riscv64-linux-gnu
<!pkg.qemu.use-upstream-vdso>, libc6-dev-riscv64-cross
<!pkg.qemu.use-upstream-vdso>,
debian/control-in:185: gcc-s390x-linux-gnu
<!pkg.qemu.use-upstream-vdso>, libc6-dev-s390x-cross
<!pkg.qemu.use-upstream-vdso>,
debian/control-in:186: gcc-x86-64-linux-gnu <!pkg.qemu.use-upstream-vdso>,

To go a bit deeper on that, building in arch-all on x86 (independent
or not) allows us to "only" need the cross compilers on x86. And not
cross compilers from all to all architectures :-).
Here a short overview of these dependencies and where they could be resolved:
$ rmadison -u ubuntu -s questing gcc-arm-linux-gnueabi
gcc-hppa-linux-gnu gcc-i686-linux-gnu gcc-loongarch64-linux-gnu
gcc-powerpc64-linux-gnu gcc-riscv64-linux-gnu gcc-s390x-linux-gnu
gcc-x86-64-linux-gnu
 gcc-arm-linux-gnueabi     | 4:15.1.0-1ubuntu1 | questing/universe |
amd64, arm64, ppc64el
 gcc-hppa-linux-gnu        | 4:15.1.0-1ubuntu1 | questing/universe |
amd64, arm64, ppc64el
 gcc-i686-linux-gnu        | 4:15.1.0-1ubuntu1 | questing          |
amd64, arm64, i386, ppc64el, s390x
 gcc-loongarch64-linux-gnu | 4:15.1.0-1ubuntu1 | questing/universe |
amd64, arm64, ppc64el
 gcc-powerpc64-linux-gnu   | 4:15.1.0-1ubuntu1 | questing/universe |
amd64, ppc64el, s390x
 gcc-riscv64-linux-gnu     | 4:15.1.0-1ubuntu1 | questing          |
amd64, arm64, i386, ppc64el, riscv64, s390x
 gcc-s390x-linux-gnu       | 4:15.1.0-1ubuntu1 | questing          |
amd64, arm64, i386, ppc64el, s390x
 gcc-x86-64-linux-gnu      | 4:15.1.0-1ubuntu1 | questing          |
amd64, arm64, i386, ppc64el, s390x

So for the time being as Sergio wrote in [1], we wanted to accept this
as-is for the time being and were considering to revisit later. I
think some could be simplified today (as you see below we do build
them now), but I do not yet see how we'd not need them for non-x86
builds. So far there has neither been a major change in how this works
nor a resource to investigate more deeply and lengthy.
Because the difference for us is that arch-all is just a step of x86.
We can not depend on the outcome of the arch-all step in the other
architectures build, the current compromise was chosen.

AFAIU these files are only used to break the dependency cycle at
build. And yes, that way something might slip as we all have seen in
the infamous example you quoted - but at least the actual final
content is built. If you look into a recent build log [2] for
'vdso-updated' and the steps before you'll see that this is not taken
as-is from the source.

Here comparing the one from source to the one shipped in a build from
that source, to show that these are the new ones.

$ md5sum /root/qemu-10.1.0~rc2+ds/linux-user/riscv/vdso-64.so
/tmp/linux-user-vdso.tar.gz/linux-user/riscv/vdso-64.so
df8aa9381fdc9a53794bb31a600051ba
/root/qemu-10.1.0~rc2+ds/linux-user/riscv/vdso-64.so
ee42fa7b62a2c9c97527a5f3d28203a8
/tmp/linux-user-vdso.tar.gz/linux-user/riscv/vdso-64.so

TL;DR AFAIU:
- Debian: ignores them, arch-indep builds them new into
qemu-system-data, that is then used in other arch builds
- Ubuntu: can't B-D on qemu-system-data from same source, hence arch
builds us the one from source, but for delivery in qemu-system-data
they are ignored too and arch-indep builds them

I'm not sure about a way out - maybe moving them to an entirely
different source and building it there comes to mind, similar to what
was done with for libslirp and userspace networking - but here that
might cause all kind of interesting dependency issues. Depending on
the older vdso from whatever the former version was? ... I do not know
 :-/

This is all brittle knowledge, again remember it is usually only
touched when it breaks :-) And these days I'm covering as a side
effort with very limited time. I outlined how I think it works, where
we are and what needs to be done. If I'm wrong somewhere please do not
chastise but teach me.

If there is a solution to further eliminate usage of the pre-built
elements at build time in Ubuntu, I think we'd all be happy to remove
them. Until then I highly appreciate Michael kept them around as is to
allow us to break the dependency cycle and not ship but use them at
build time.

[1]: https://git.launchpad.net/ubuntu/+source/qemu/commit/?id=f6428410aabd40e9b3c4889a6a157fb687294df8
[2]: https://launchpadlibrarian.net/804034172/buildlog_ubuntu-questing-amd64.qemu_1%3A10.0.2+ds-1ubuntu2_BUILDING.txt.gz