x86: retf or iret pagefault sets wrong error code

[Zdeněk Sojka]

With a x86_64 or i386 guest, non-KVM, when trying to execute a
"iret/iretq/retf" instruction in userspace with invalid stack pointer
(under a protected mode OS, like Linux), wrong bits are set in the
pushed error code; bit 2 is not set, indicating the error comes from
kernel space.

If the guest OS is using this flag to decide whether this was a kernel
or user page fault, it will mistakenly decide a kernel has irrecoverably
faulted, possibly causing guest OS panic.

How to reproduce the problem a guest (non-KVM) Linux:
Note, on recent Linux kernel version, this needs a CPU with SMAP support
(eg. -cpu max)

$ cat tst.c
int main()
{
__asm__ volatile (
"mov $0,%esp\n"
"retf"
);
return 0;
}

$ gcc tst.c
$ ./a.out
Killed

"dmesg" shows the kernel has in fact triggered a "BUG: unable to handle
kernel NULL pointer dereference...", but it has "recovered" by killing
the faulting process (see attached screenshot).

Using self-compiled qemu from git:
commit 532cc6da74ec25b5ba6893b5757c977d54582949 (HEAD -> master, tag: v4.0.0-rc3, origin/master, origin/HEAD)
Author: Peter Maydell <email address hidden>
Date: Wed Apr 10 15:38:59 2019 +0100

    Update version for v4.0.0-rc3 release

    Signed-off-by: Peter Maydell <email address hidden>

[Robert Henry (mhodog)]

This appears to be similar to https://bugs.launchpad.net/qemu/+bug/1866892 (and much simpler)

[Thomas Huth (th-huth)]

This is an automated cleanup. This bug report has been moved to QEMU's
new bug tracker on gitlab.com and thus gets marked as 'expired' now.
Please continue with the discussion here:

 https://gitlab.com/qemu-project/qemu/-/issues/265