Use the same machine type regardless of has_virt: q35 with accelerators
list set to kvm:tcg, this will use KVM if available and fall back to TCG
if not available so there's no point checking has_virt. We can't
reliably know if KVM is usable anyway: even if the CPU has the
virtualization extensions, the support might not be enabled in the QEMU
build or there may be no kernel module or we may be calling a different
qemu executable than the one supporting KVM.
Set CPU type to "host" if KVM available and "max" otherwise because
"host" is not supported without KVM. We actually want to emulate the
host CPU as closely as possible so that host executables can run even if
optimized for the specific CPU. "max" seems to be the new way (since
Feb only) to request "host" cpu without KVM. It seems that the idea is
for "max" to become same as "host" if KVM is enabled so at some point we
will want to switch to using "max" in both cases.
The "level=9" flag seems to have been an error, there's no CPU with
cpuid max level of 9 and I can't see the purpose of setting the cpuid
level other than the host cpu's level.
-enable-kvm is redundant with accel=kvm:tcg in current qemu.
Again I'm not able to test this patch on a cpu that would be affected
by it but I hope this fixes some situations which are currently broken
anyway.
Update check_virtualization to check for the SVM on x86, KVM supports
both VMX and SVM. Fix the clobber list of the VMX check: memory is not
clobbered while ebx and edx are (ecx is already marked as output).
I'm not able to test this patch on a cpu that would be affected by it
but I don't think test-runner has been tested on those cpus yet.
==27901== Conditional jump or move depends on uninitialised value(s)
==27901== at 0x41157A: handshake_util_find_pmkid_kde
(handshake.c:537)
==27901== by 0x40E03A: eapol_handle_ptk_1_of_4 (eapol.c:852)
==27901== by 0x40F3CD: eapol_key_handle (eapol.c:1417)
==27901== by 0x40F955: eapol_rx_packet (eapol.c:1607)
==27901== by 0x410321: __eapol_rx_packet (eapol.c:1915)
Agent implementation inside agent.c takes a reference of the trigger
message associated with the request. When the callback is called, the
message is passed as an argument. The callback is responsible for
taking the message reference if necessary. Once the callback returns,
agent releases its reference.
For error paths, our code was using dbus_pending_reply which in turn
uses dbus_message_unref. This caused the agent to try an unref
operation on an already freed object.
Move the calling of the *_shutdown functions from the signal handler to
a new public function, and use that function inside the DBus disconnect
handler to make sure resources are cleanly released.
Skip the matching of the PMKID KDE to the PMKID list in the RSNE if
we've seen a new EAP authentication before the step 1/4 was received.
That would mean that the server had not accepted the PMKIDs we submitted
and we performed a new 8021X authentication, producing a new PMKSA which
won't be on the list in the RSNE.
Unfortunately this doesn't currently ensure that the preauthentication
has succeeded and that later the PMKSA from the preauthentication was
used in the transition, only that the preauthentication process doesn't
break the transition. For now this can be confirmed by looking at the
testrunner -v output to see that the line "EAP completed with eapSuccess"
appears before the following line, and not after:
src/device.c:device_enter_state() Old State: connected, new state: roaming
