QEMU mishandling of SO_PEERSEC forces systemd into tight loop
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
QEMU |
Fix Released
|
Undecided
|
Laurent Vivier |
Bug Description
While building Debian images for embedded ARM target systems I detected that QEMU seems to force newer systemd daemons into a tight loop.
My setup is the following:
Host machine: Ubuntu 18.04, amd64
LXD container: Debian Buster, arm64, systemd 241
QEMU: qemu-aarch64-
To easily reproduce the issue I have created the following repository:
https:/
The call where systemd gets looping is the following:
2837 getsockopt(
Furthermore I also verified that the issue is not related to LXD.
The same behavior can be reproduced using systemd-nspawn.
This issue reported against systemd seems to be related:
https:/
tags: | added: linux-user |
tags: | added: arm |
Changed in qemu: | |
status: | New → Confirmed |
Changed in qemu: | |
assignee: | nobody → Laurent Vivier (laurent-vivier) |
As described on the systemd issue, the syscall we're getting wrong here is getsockopt(fd, SOL_SOCKET, SO_PEERSEC, ...). Our linux-user/ syscall. c:do_getsockopt () doesn't have any special case code for the payload on this function, so we treat it as if it were just an integer payload, which is not correct here.
Unfortunately I can't find any documentation on exactly what SO_PEERSEC does or what the payload format is, which makes it pretty hard to fix this bug :-( It's not listed in the socket(7) manpage -- https:/ /linux. die.net/ man/7/socket -- which is where I'd expect to find it, and the kernel source code is pretty confusing in this area.