QEMU malfunctioning if built with FORTIFY_SOURCE=3

QEMU malfunctioning if built with FORTIFY_SOURCE=3

[Dario Faggioli]

[-- Attachment #1: Type: text/plain, Size: 3056 bytes --]

Hello Everyone!

So, I'm not sure how much this would be interesting, but I thought
about reporting it anyways, then let's see.

A few days ago we started to build openSUSE_Tumbleweed packages with
-D_FORTIFY_SOURCES=3 by default (it was =2 before, and it's back to =2
again now, at least for QEMU :-/).

It seemed fine, but then we discovered that a QEMU built that way, does
not work properly. In fact, it crashes pretty early displaying a
message like this: "*** buffer overflow detected ***"

I've had a look around, and did not find anything about previous
attempts of doing that, or things to be aware of, in general, if doing
it.

Now, for now, I don't have many other info myself either. Just some
terminal logs from a few users, and from our automated testing system,
i.e., like this:

$ sudo virsh start VM1
error: Failed to start domain 'VM1'
error: internal error: qemu unexpectedly closed the monitor: qxl_send_events: spice-server bug: guest stopped, ignoring
*** buffer overflow detected ***: terminated

Or this:

error: Failed to start domain 'vm-swtpm-legacy'
error: internal error: qemu unexpectedly closed the monitor: 2022-05-25T16:30:05.738186Z qemu-system-x86_64: -accel kvm: warning: Number of SMP cpus requested (2) exceeds the recommended cpus supported by KVM (1)
2022-05-25T16:30:05.738259Z qemu-system-x86_64: -accel kvm: warning: Number of hotpluggable cpus requested (2) exceeds the recommended cpus supported by KVM (1)
2022-05-25T16:30:05.742354Z qemu-system-x86_64: warning: host doesn't support requested feature: MSR(48FH).vmx-exit-load-perf-global-ctrl [bit 12]
2022-05-25T16:30:05.742369Z qemu-system-x86_64: warning: host doesn't support requested feature: MSR(490H).vmx-entry-load-perf-global-ctrl [bit 13]
2022-05-25T16:30:05.743989Z qemu-system-x86_64: warning: host doesn't support requested feature: MSR(48FH).vmx-exit-load-perf-global-ctrl [bit 12]
2022-05-25T16:30:05.744050Z qemu-system-x86_64: warning: host doesn't support requested feature: MSR(490H).vmx-entry-load-perf-global-ctrl [bit 13]
*** buffer overflow detected ***: terminated

Or this:
https://openqa.opensuse.org/tests/2375666#step/usr_sbin_dnsmasq/47
https://xenbits.xen.org/people/dariof/download.png (also here, in case
the image disappears from OpenQA)

I am planning to try to investigate this more, but not right away. And
I can't even tell for sure when I'll have time for it. So, this is just
for letting people know that this has been (quickly) attempted, and
that it currently does not work, in case it's interesting for anyone
else.

Of course, in case it's the other way around, i.e., someone already has
more info on the subject that I've not been able to find, feel free to
ping me. :-)

Thanks and Regards
-- 
Dario Faggioli, Ph.D
http://about.me/dario.faggioli
Virtualization Software Engineer
SUSE Labs, SUSE https://www.suse.com/
-------------------------------------------------------------------
<<This happens because _I_ choose it to happen!>> (Raistlin Majere)

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: QEMU malfunctioning if built with FORTIFY_SOURCE=3

[Claudio Fontana]

On 5/27/22 18:55, Dario Faggioli wrote:
> Hello Everyone!
> 
> So, I'm not sure how much this would be interesting, but I thought
> about reporting it anyways, then let's see.
> 
> A few days ago we started to build openSUSE_Tumbleweed packages with
> -D_FORTIFY_SOURCES=3 by default (it was =2 before, and it's back to =2
> again now, at least for QEMU :-/).
> 
> It seemed fine, but then we discovered that a QEMU built that way, does
> not work properly. In fact, it crashes pretty early displaying a
> message like this: "*** buffer overflow detected ***"

Hi Dario and all,

I just sent a fix to the list,

with the Subject

"[PATCH] pci: fix overflow in printf string formatting"

That should fix the issue,

Thanks,

Claudio

> 
> I've had a look around, and did not find anything about previous
> attempts of doing that, or things to be aware of, in general, if doing
> it.
> 
> Now, for now, I don't have many other info myself either. Just some
> terminal logs from a few users, and from our automated testing system,
> i.e., like this:
> 
> $ sudo virsh start VM1
> error: Failed to start domain 'VM1'
> error: internal error: qemu unexpectedly closed the monitor: qxl_send_events: spice-server bug: guest stopped, ignoring
> *** buffer overflow detected ***: terminated
> 
> Or this:
> 
> error: Failed to start domain 'vm-swtpm-legacy'
> error: internal error: qemu unexpectedly closed the monitor: 2022-05-25T16:30:05.738186Z qemu-system-x86_64: -accel kvm: warning: Number of SMP cpus requested (2) exceeds the recommended cpus supported by KVM (1)
> 2022-05-25T16:30:05.738259Z qemu-system-x86_64: -accel kvm: warning: Number of hotpluggable cpus requested (2) exceeds the recommended cpus supported by KVM (1)
> 2022-05-25T16:30:05.742354Z qemu-system-x86_64: warning: host doesn't support requested feature: MSR(48FH).vmx-exit-load-perf-global-ctrl [bit 12]
> 2022-05-25T16:30:05.742369Z qemu-system-x86_64: warning: host doesn't support requested feature: MSR(490H).vmx-entry-load-perf-global-ctrl [bit 13]
> 2022-05-25T16:30:05.743989Z qemu-system-x86_64: warning: host doesn't support requested feature: MSR(48FH).vmx-exit-load-perf-global-ctrl [bit 12]
> 2022-05-25T16:30:05.744050Z qemu-system-x86_64: warning: host doesn't support requested feature: MSR(490H).vmx-entry-load-perf-global-ctrl [bit 13]
> *** buffer overflow detected ***: terminated
> 
> Or this:
> https://openqa.opensuse.org/tests/2375666#step/usr_sbin_dnsmasq/47
> https://xenbits.xen.org/people/dariof/download.png (also here, in case
> the image disappears from OpenQA)
> 
> I am planning to try to investigate this more, but not right away. And
> I can't even tell for sure when I'll have time for it. So, this is just
> for letting people know that this has been (quickly) attempted, and
> that it currently does not work, in case it's interesting for anyone
> else.
> 
> Of course, in case it's the other way around, i.e., someone already has
> more info on the subject that I've not been able to find, feel free to
> ping me. :-)
> 
> Thanks and Regards