- 06 Feb, 2019 40 commits
-
-
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:
Thomas Gleixner <tglx@linutronix.de> Reviewed-by:
Paolo Bonzini <pbonzini@redhat.com> Cc: Liran Alon <liran.alon@oracle.com> Cc: Nadav Amit <nadav.amit@gmail.com> Cc: Borislav Petkov <bp@alien8.de> Cc: Tom Lendacky <thomas.lendacky@amd.com> Signed-off-by:
David Woodhouse <dwmw@amazon.co.uk> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> (backported from commit 7a1eac80 linux-stable) [juergh: Adjusted context.] 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:
-
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:
-
Andy Whitcroft authored
When we install linux-image we have to run kernel postinst.d support in case this kernel has no linux-image-extra. Should it have an extra and we install we then have to assume that is being installed cold and that the same processing is neeed. If we are installing both at the same time, we necessarily trigger kernel postinst.d twice. As this includes rebuilding the initramfs and reconfiguring the boot loader this is very inefficient. For removal of linux-image-extra when we remove the package we also need to run postinst.d handling in order to pare down the initramfs to linux-image contents only. However when we are removing both packages we immediatly remove the rebuilt initramfs. Doubly annoying. This patch switches us to using a trigger against the linux-image package for all postinst.d and postrm.d handling. On installation postinst.d gets triggered twice once by linux-image and once by linux-image-extra. As triggers are non-cumulative we will only run this processing once. When removing both packages we will trigger postinst.d from linux-image-extra and then in linux-image postrm.d we effectivly ignore the pending trigger and simply run the postrm.d. This prevents us from rebuilding the initramfs. BugLink: http://bugs.launchpad.net/bugs/1764794Signed-off-by:
-
