- 06 Feb, 2019 40 commits
-
-
Thomas Gleixner authored
BugLink: https://bugs.launchpad.net/bugs/1811646 commit 024d83ca upstream. Mikhail reported the following lockdep splat: WARNING: possible irq lock inversion dependency detected CPU 0/KVM/10284 just changed the state of lock: 000000000d538a88 (&st->lock){+...}, at: speculative_store_bypass_update+0x10b/0x170 but this lock was taken by another, HARDIRQ-safe lock in the past: (&(&sighand->siglock)->rlock){-.-.} and interrupts could create inverse lock ordering between them. Possible interrupt unsafe locking scenario: CPU0 CPU1 ---- ---- lock(&st->lock); local_irq_disable(); lock(&(&sighand->siglock)->rlock); lock(&st->lock); <Interrupt> lock(&(&sighand->siglock)->rlock); *** DEADLOCK *** The code path which connects those locks is: speculative_store_bypass_update() ssb_prctl_set() do_seccomp() do_syscall_64() In svm_vcpu_run() speculative_store_bypass_update() is called with interupts enabled via x86_virt_spec_ctrl_set_guest/host(). This is actually a false positive, because GIF=0 so interrupts are disabled even if IF=1; however, we can easily move the invocations of x86_virt_spec_ctrl_set_guest/host() into the interrupt disabled region to cure it, and it's a good idea to keep the GIF=0/IF=1 area as small and self-contained as possible. Fixes: 1f50ddb4 ("x86/speculation: Handle HT correctly on AMD") Reported-by:
Mikhail Gavrilov <mikhail.v.gavrilov@gmail.com> Signed-off-by:
Thomas Gleixner <tglx@linutronix.de> Tested-by:
Paolo Bonzini <pbonzini@redhat.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> (cherry picked from commit cd4574c1 linux-stable) Signed-off-by:
Juerg Haefliger <juergh@canonical.com> Acked-by:
Stefan Bader <stefan.bader@canonical.com> Acked-by:
Kleber Sacilotto de Souza <kleber.souza@canonical.com> Signed-off-by:
-
Wanpeng Li authored
BugLink: https://bugs.launchpad.net/bugs/1811646 commit 518e7b94 upstream Linux (among the others) has checks to make sure that certain features aren't enabled on a certain family/model/stepping if the microcode version isn't greater than or equal to a known good version. By exposing the real microcode version, we're preventing buggy guests that don't check that they are running virtualized (i.e., they should trust the hypervisor) from disabling features that are effectively not buggy. Suggested-by:
Filippo Sironi <sironi@amazon.de> Signed-off-by:
Wanpeng Li <wanpengli@tencent.com> Signed-off-by:
Radim Krčmář <rkrcmar@redhat.com> Signed-off-by:
David Woodhouse <dwmw@amazon.co.uk> Signed-off-by:
-
Tom Lendacky authored
BugLink: https://bugs.launchpad.net/bugs/1811646 commit d1d93fa9 upstream In order to determine if LFENCE is a serializing instruction on AMD processors, MSR 0xc0011029 (MSR_F10H_DECFG) must be read and the state of bit 1 checked. This patch will add support to allow a guest to properly make this determination. Add the MSR feature callback operation to svm.c and add MSR 0xc0011029 to the list of MSR-based features. If LFENCE is serializing, then the feature is supported, allowing the hypervisor to set the value of the MSR that guest will see. Support is also added to write (hypervisor only) and read the MSR value for the guest. A write by the guest will result in a #GP. A read by the guest will return the value as set by the host. In this way, the support to expose the feature to the guest is controlled by the hypervisor. Signed-off-by:
Tom Lendacky <thomas.lendacky@amd.com> Signed-off-by:
-
Jim Mattson authored
BugLink: https://bugs.launchpad.net/bugs/1811646 commit 1eaafe91 upstream. If there is a possibility that a VM may migrate to a Skylake host, then the hypervisor should report IA32_ARCH_CAPABILITIES.RSBA[bit 2] as being set (future work, of course). This implies that CPUID.(EAX=7,ECX=0):EDX.ARCH_CAPABILITIES[bit 29] should be set. Therefore, kvm should report this CPUID bit as being supported whether or not the host supports it. Userspace is still free to clear the bit if it chooses. For more information on RSBA, see Intel's white paper, "Retpoline: A Branch Target Injection Mitigation" (Document Number 337131-001), currently available at https://bugzilla.kernel.org/show_bug.cgi?id=199511. Since the IA32_ARCH_CAPABILITIES MSR is emulated in kvm, there is no dependency on hardware support for this feature. Signed-off-by:
Jim Mattson <jmattson@google.com> Reviewed-by:
Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Fixes: 28c1c9fa ("KVM/VMX: Emulate MSR_IA32_ARCH_CAPABILITIES") Cc: stable@vger.kernel.org Signed-off-by:
-
Paolo Bonzini authored
BugLink: https://bugs.launchpad.net/bugs/1811646 commit 946fbbc1 upstream. vmx_vcpu_run() and svm_vcpu_run() are large functions, and giving branch hints to the compiler can actually make a substantial cycle difference by keeping the fast path contiguous in memory. With this optimization, the retpoline-guest/retpoline-host case is about 50 cycles faster. Signed-off-by:
Ingo Molnar <mingo@kernel.org> Signed-off-by:
-
KarimAllah Ahmed authored
BugLink: https://bugs.launchpad.net/bugs/1811646 commit 206587a9 upstream. These two variables should check whether SPEC_CTRL and PRED_CMD are supposed to be passed through to L2 guests or not. While msr_write_intercepted_l01 would return 'true' if it is not passed through. So just invert the result of msr_write_intercepted_l01 to implement the correct semantics. Signed-off-by:
KarimAllah Ahmed <karahmed@amazon.de> Signed-off-by:
-
Jim Mattson authored
BugLink: https://bugs.launchpad.net/bugs/1811646 After a successful VM-entry with the "VMCS shadowing" VM-execution control set, the shadow VMCS referenced by the VMCS link pointer field in the current VMCS becomes active on the logical processor. A VMCS that is made active on more than one logical processor may become corrupted. Therefore, before an active VMCS can be migrated to another logical processor, the first logical processor must execute a VMCLEAR for the active VMCS. VMCLEAR both ensures that all VMCS data are written to memory and makes the VMCS inactive. Signed-off-by:
David Matlack <dmatlack@google.com> Message-Id: <1477668579-22555-1-git-send-email-jmattson@google.com> Signed-off-by:
-
Paolo Bonzini authored
BugLink: https://bugs.launchpad.net/bugs/1811646 This causes an ugly dmesg splat. Beautified syzkaller testcase: #include <unistd.h> #include <sys/syscall.h> #include <sys/ioctl.h> #include <fcntl.h> #include <linux/kvm.h> long r[8]; int main() { struct kvm_cpuid2 c = { 0 }; r[2] = open("/dev/kvm", O_RDWR); r[3] = ioctl(r[2], KVM_CREATE_VM, 0); r[4] = ioctl(r[3], KVM_CREATE_VCPU, 0x8); r[7] = ioctl(r[4], KVM_SET_CPUID, &c); return 0; } Reported-by:
Dmitry Vyukov <dvyukov@google.com> Signed-off-by:
-
Andy Whitcroft authored
BugLink: http://bugs.launchpad.net/bugs/1806380Signed-off-by:
Andy Whitcroft <apw@canonical.com> Signed-off-by:
Seth Forshee <seth.forshee@canonical.com> Signed-off-by:
-
Andy Whitcroft authored
Traditionally we have tried to download all and any packages we can find. If we have any packages we just assume that what we got is a consistent set and use it. This leads to incomplete sets being committed on network failure. Firstly detect and differentiate transport errors and valid missing packages. Secondly switch to analysing known good package set combinations; this relies on the presumption that the publisher only publishes all or none of a binary package set. This lets us throw errors when we are unable to find an internally consistent set of packages. BugLink: http://bugs.launchpad.net/bugs/1806380Signed-off-by:
-
Andy Whitcroft authored
BugLink: http://bugs.launchpad.net/bugs/1806380Signed-off-by:
-
Andy Whitcroft authored
BugLink: http://bugs.launchpad.net/bugs/1806380Signed-off-by:
Kamal Mostafa <kamal@canonical.com> Signed-off-by:
-
Andy Whitcroft authored
In getabis we extract the compiler information from an arbitrary .ko. As we will not have those when only using buildinfo ABI information we need to collect the compiler information during the build. BugLink: http://bugs.launchpad.net/bugs/1806380Signed-off-by:
-
Andy Whitcroft authored
In getabis we extract the firmware information from each of the .kos. As we will not have those when only using buildinfo ABI information we need to collect the firmware information during the build. BugLink: http://bugs.launchpad.net/bugs/1806380Signed-off-by:
-
Andy Whitcroft authored
BugLink: http://bugs.launchpad.net/bugs/1806380Signed-off-by:
-
Andy Whitcroft authored
BugLink: http://bugs.launchpad.net/bugs/1806380Signed-off-by:
-
Andy Whitcroft authored
BugLink: http://bugs.launchpad.net/bugs/1806380Signed-off-by:
-
Andy Whitcroft authored
BugLink: http://bugs.launchpad.net/bugs/1806380Signed-off-by:
-
Marcelo Henrique Cerri authored
Skip the inclusion of init file into the -cloud-tools-common package when do_tools_common is false. That's necessary in order to support linux-azure, that ships hyper-v tools but does not ship the common bits. BugLink: http://bugs.launchpad.net/bugs/1764794Signed-off-by:
Marcelo Henrique Cerri <marcelo.cerri@canonical.com> Signed-off-by:
-
Kamal Mostafa authored
Required for do_libc_dev_package=false to not break the build. BugLink: http://bugs.launchpad.net/bugs/1764794Signed-off-by:
-
Andy Whitcroft authored
BugLink: http://bugs.launchpad.net/bugs/1764794Signed-off-by:
-
Seth Forshee authored
Currently 3-binary-indep.mk performs cloud packaging steps if do_tools_common is true, which can cause errors if the cloud-tools package isn't defined in the control file. Make these steps depend on do_cloud_tools and do_tools_hyperv as appropriate. BugLink: http://bugs.launchpad.net/bugs/1764794Signed-off-by:
-
Andy Whitcroft authored
BugLink: http://bugs.launchpad.net/bugs/1764794Signed-off-by:
-
Seth Forshee authored
BugLink: http://bugs.launchpad.net/bugs/1764794 OldBugLink: http://bugs.launchpad.net/bugs/1734130 IBM has requested that we package the kvm_stat tool from the kernel source tree. This is a python script and thus is not kernel-version specific. Because of this, and in order to avoid adding a python dependency, this tool is not added to any existing tools package. Instead, create a new linux-tools-host package to contain tools useful on VM hosts which will currently only contain kvm_stat. Don't build this package unless specified in the architecture rules file; it should only be built in the master kernel and in a single architecture for any given series. Signed-off-by:
Thadeu Lima de Souza Cascardo <cascardo@canonical.com> Signed-off-by:
-
Kamal Mostafa authored
BugLink: http://bugs.launchpad.net/bugs/1764794Signed-off-by:
-
Andy Whitcroft authored
do_common_tools is a mode specifier, it is on when we want tools and off when we do not want tools. It is intended to be flipped by the bootstrap modes. Whether those common tools are actually built is determined by whether we are calling binary or binary-arch not related to whether we want those packages to have content. Enable this unconditionally. This allows us to build the indep packages on any arch is needed. BugLink: http://bugs.launchpad.net/bugs/1764794Signed-off-by:
-
Kamal Mostafa authored
If optional .mk variable 'ship_extras_package' is explicitly set to false, then do not construct the linux-image-extra package; instead just log all of the "extra" modules which were pointlessly built yet won't be shipped. This feature may be useful for config debugging and for custom kernel development. BugLink: http://bugs.launchpad.net/bugs/1764794Signed-off-by:
Tim Gardner <tim.gardner@canonical.com> Acked-by:
Brad Figg <brad.figg@canonical.com> (cherry-picked from commit f16de3c17fcbbcf01c81f2897e4b8fe4a5ca470c bionic) Signed-off-by:
-
Andy Whitcroft authored
BugLink: http://bugs.launchpad.net/bugs/1764794 OldBugLink: http://bugs.launchpad.net/bugs/1717920Signed-off-by:
-
Andy Whitcroft authored
BugLink: http://bugs.launchpad.net/bugs/1764794Signed-off-by:
-
Andy Whitcroft authored
BugLink: http://bugs.launchpad.net/bugs/1764794Signed-off-by:
-
Andy Whitcroft authored
BugLink: http://bugs.launchpad.net/bugs/1764794Signed-off-by:
-
Andy Whitcroft authored
BugLink: http://bugs.launchpad.net/bugs/1764794 OldBugLink: http://bugs.launchpad.net/bugs/1637473Signed-off-by:
-
Andy Whitcroft authored
BugLink: http://bugs.launchpad.net/bugs/1764794 OldBugLink: http://bugs.launchpad.net/bugs/1637473Signed-off-by:
-
Tim Gardner authored
BugLink: http://bugs.launchpad.net/bugs/1764794Signed-off-by:
-
Tim Gardner authored
BugLink: http://bugs.launchpad.net/bugs/1764794Signed-off-by:
-
Andy Whitcroft authored
BugLink: http://bugs.launchpad.net/bugs/1764794 OldBugLink: http://bugs.launchpad.net/bugs/1696154Signed-off-by:
-
Seth Forshee authored
BugLink: http://bugs.launchpad.net/bugs/1764794 OldBugLink: http://bugs.launchpad.net/bugs/1766391 There's a typo in the headers postinst which prevents triggering of dkms builds on installation. Change this to use the correct path, /etc/kernel/header_postinst.d. Signed-off-by:
-
Andy Whitcroft authored
BugLink: http://bugs.launchpad.net/bugs/1764794Signed-off-by:
-
Andy Whitcroft authored
When we are signing for an architecture switch to producing a linux-image-unsigned package from the primary source. linux-signed will then produce the linux-image package which will be signed. We expect all consumers to use the signed form even if they are not utilising the signature. BugLink: http://bugs.launchpad.net/bugs/1764794Signed-off-by:
-
Andy Whitcroft authored
BugLink: http://bugs.launchpad.net/bugs/1764794Signed-off-by:
-
