- 20 Apr, 2016 35 commits
-
-
Paolo Bonzini authored
BugLink: http://bugs.launchpad.net/bugs/1572722 commit ef697a71 upstream. Old KVM guests invoke single-context invvpid without actually checking whether it is supported. This was fixed by commit 518c8aee ("KVM: VMX: Make sure single type invvpid is supported before issuing invvpid instruction", 2010-08-01) and the patch after, but pre-2.6.36 kernels lack it including RHEL 6. Reported-by: jmontleo@redhat.com Tested-by: jmontleo@redhat.com Fixes: 99b83ac8Reviewed-by:
David Matlack <dmatlack@google.com> Signed-off-by:
Paolo Bonzini <pbonzini@redhat.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by:
Tim Gardner <tim.gardner@canonical.com>
-
Paolo Bonzini authored
BugLink: http://bugs.launchpad.net/bugs/1572722 commit f6870ee9 upstream. A guest executing an invalid invvpid instruction would hang because the instruction pointer was not updated. Reported-by: jmontleo@redhat.com Tested-by: jmontleo@redhat.com Fixes: 99b83ac8Reviewed-by:
-
Paolo Bonzini authored
BugLink: http://bugs.launchpad.net/bugs/1572722 commit 2849eb4f upstream. A guest executing an invalid invept instruction would hang because the instruction pointer was not updated. Fixes: bfd0a56bReviewed-by:
-
Paolo Bonzini authored
BugLink: http://bugs.launchpad.net/bugs/1572722 commit e9ad4ec8 upstream. Moving the initialization earlier is needed in 4.6 because kvm_arch_init_vm is now using mmu_lock, causing lockdep to complain: [ 284.440294] INFO: trying to register non-static key. [ 284.445259] the code is fine but needs lockdep annotation. [ 284.450736] turning off the locking correctness validator. ... [ 284.528318] [<ffffffff810aecc3>] lock_acquire+0xd3/0x240 [ 284.533733] [<ffffffffa0305aa0>] ? kvm_page_track_register_notifier+0x20/0x60 [kvm] [ 284.541467] [<ffffffff81715581>] _raw_spin_lock+0x41/0x80 [ 284.546960] [<ffffffffa0305aa0>] ? kvm_page_track_register_notifier+0x20/0x60 [kvm] [ 284.554707] [<ffffffffa0305aa0>] kvm_page_track_register_notifier+0x20/0x60 [kvm] [ 284.562281] [<ffffffffa02ece70>] kvm_mmu_init_vm+0x20/0x30 [kvm] [ 284.568381] [<ffffffffa02dbf7a>] kvm_arch_init_vm+0x1ea/0x200 [kvm] [ 284.574740] [<ffffffffa02bff3f>] kvm_dev_ioctl+0xbf/0x4d0 [kvm] However, it also helps fixing a preexisting problem, which is why this patch is also good for stable kernels: kvm_create_vm was incrementing current->mm->mm_count but not decrementing it at the out_err label (in case kvm_init_mmu_notifier failed). The new initialization order makes it possible to add the required mmdrop without adding a new error label. Reported-by:
Borislav Petkov <bp@alien8.de> Signed-off-by:
-
Radim Krčmář authored
BugLink: http://bugs.launchpad.net/bugs/1572722 commit 7dd0fdff upstream. Discard policy uses ack_notifiers to prevent injection of PIT interrupts before EOI from the last one. This patch changes the policy to always try to deliver the interrupt, which makes a difference when its vector is in ISR. Old implementation would drop the interrupt, but proposed one injects to IRR, like real hardware would. The old policy breaks legacy NMI watchdogs, where PIT is used through virtual wire (LVT0): PIT never sends an interrupt before receiving EOI, thus a guest deadlock with disabled interrupts will stop NMIs. Note that NMI doesn't do EOI, so PIT also had to send a normal interrupt through IOAPIC. (KVM's PIT is deeply rotten and luckily not used much in modern systems.) Even though there is a chance of regressions, I think we can fix the LVT0 NMI bug without introducing a new tick policy. Reported-by:
Yuki Shibuya <shibuya.yk@ncos.nec.co.jp> Reviewed-by:
Radim Krčmář <rkrcmar@redhat.com> Signed-off-by:
-
Bjorn Helgaas authored
BugLink: http://bugs.launchpad.net/bugs/1572722 commit b8941571 upstream. The Home Agent and PCU PCI devices in Broadwell-EP have a non-BAR register where a BAR should be. We don't know what the side effects of sizing the "BAR" would be, and we don't know what address space the "BAR" might appear to describe. Mark these devices as having non-compliant BARs so the PCI core doesn't touch them. Signed-off-by:
Bjorn Helgaas <bhelgaas@google.com> Tested-by:
Andi Kleen <ak@linux.intel.com> Signed-off-by:
-
Stephane Eranian authored
BugLink: http://bugs.launchpad.net/bugs/1572722 commit 5690ae28 upstream. This patch adds a definition for GLOBAL_OVFL_STATUS bit 55 which is used with the Processor Trace (PT) feature. Signed-off-by:
Stephane Eranian <eranian@google.com> Signed-off-by:
Peter Zijlstra (Intel) <peterz@infradead.org> Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com> Cc: Arnaldo Carvalho de Melo <acme@redhat.com> Cc: Jiri Olsa <jolsa@redhat.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Vince Weaver <vincent.weaver@maine.edu> Cc: adrian.hunter@intel.com Cc: kan.liang@intel.com Cc: namhyung@kernel.org Link: http://lkml.kernel.org/r/1457034642-21837-2-git-send-email-eranian@google.comSigned-off-by:
Ingo Molnar <mingo@kernel.org> Signed-off-by:
-
Andy Lutomirski authored
BugLink: http://bugs.launchpad.net/bugs/1572722 commit 4e79e182 upstream. Signal delivery needs to know the sign of an interrupted syscall's return value in order to detect -ERESTART variants. Normally this works independently of bitness because syscalls internally return long. Under ptrace, however, this can break, and syscall_get_error is supposed to sign-extend regs->ax if needed. We were clearing TS_COMPAT too early, though, and this prevented sign extension, which subtly broke syscall restart under ptrace. Reported-by:
Robert O'Callahan <robert@ocallahan.org> Signed-off-by:
Andy Lutomirski <luto@kernel.org> Cc: Al Viro <viro@zeniv.linux.org.uk> Cc: Andy Lutomirski <luto@amacapital.net> Cc: Borislav Petkov <bp@alien8.de> Cc: Brian Gerst <brgerst@gmail.com> Cc: Denys Vlasenko <dvlasenk@redhat.com> Cc: H. Peter Anvin <hpa@zytor.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Shuah Khan <shuahkh@osg.samsung.com> Cc: Thomas Gleixner <tglx@linutronix.de> Fixes: c5c46f59 ("x86/entry: Add new, comprehensible entry and exit handlers written in C") Link: http://lkml.kernel.org/r/cbce3cf545522f64eb37f5478cb59746230db3b5.1455142412.git.luto@kernel.orgSigned-off-by:
-
Borislav Petkov authored
BugLink: http://bugs.launchpad.net/bugs/1572722 commit 5f9c01aa upstream. Thomas Voegtle reported that doing oldconfig with a .config which has CONFIG_MICROCODE enabled but BLK_DEV_INITRD disabled prevents the microcode loading mechanism from being built. So untangle it from the BLK_DEV_INITRD dependency so that oldconfig doesn't turn it off and add an explanatory text to its Kconfig help what the supported methods for supplying microcode are. Reported-by:
Thomas Voegtle <tv@lio96.de> Tested-by:
Borislav Petkov <bp@suse.de> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Link: http://lkml.kernel.org/r/1454499225-21544-2-git-send-email-bp@alien8.deSigned-off-by:
-
Borislav Petkov authored
BugLink: http://bugs.launchpad.net/bugs/1572722 commit 264285ac upstream. Set the initrd @start depending on the presence of an initrd. Otherwise, builtin microcode loading doesn't work as the start is wrong and we're using it to compute offset to the microcode blobs. Tested-by:
-
Chris Paterson authored
BugLink: http://bugs.launchpad.net/bugs/1572722 commit a32ef81c upstream. Commit 27cbd7e8 ("mmc: sh_mmcif: rework dma channel handling") introduced a typo causing the TX DMA channel allocation to be overwritten by the requested RX DMA channel. Fixes: 27cbd7e8 ("mmc: sh_mmcif: rework dma channel handling") Signed-off-by:
Chris Paterson <chris.paterson2@renesas.com> Acked-by:
Laurent Pinchart <laurent.pinchart@ideasonboard.com> Acked-by:
Arnd Bergmann <arnd@arndb.de> Signed-off-by:
Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by:
-
Arnd Bergmann authored
BugLink: http://bugs.launchpad.net/bugs/1572722 commit 27cbd7e8 upstream. When compiling the sh_mmcif driver for ARM64, we currently get a harmless build warning: ../drivers/mmc/host/sh_mmcif.c: In function 'sh_mmcif_request_dma_one': ../drivers/mmc/host/sh_mmcif.c:417:4: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast] (void *)pdata->slave_id_tx : ^ ../drivers/mmc/host/sh_mmcif.c:418:4: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast] (void *)pdata->slave_id_rx; This could be worked around by adding another cast to uintptr_t, but I decided to simplify the code a little more to avoid that. This splits out the platform data using code into a separate function and builds that only for CONFIG_SUPERH. This part still has a typecast but does not need a second one. The SH platform code could be further modified to pass a pointer directly as we do on other architectures when we have a filter function. The normal case is simplified further and now just calls dma_request_slave_channel() directly without going through the compat handling. Signed-off-by:
-
Arnd Bergmann authored
BugLink: http://bugs.launchpad.net/bugs/1572722 commit b9a1a743 upstream. ARM64 allmodconfig produces a bunch of warnings when building the samsung ASoC code: sound/soc/samsung/dmaengine.c: In function 'samsung_asoc_init_dma_data': sound/soc/samsung/dmaengine.c:53:32: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast] playback_data->filter_data = (void *)playback->channel; sound/soc/samsung/dmaengine.c:60:31: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast] capture_data->filter_data = (void *)capture->channel; We could easily shut up the warning by adding an intermediate cast, but there is a bigger underlying problem: The use of IORESOURCE_DMA to pass data from platform code to device drivers is dubious to start with, as what we really want is a pointer that can be passed into a filter function. Note that on s3c64xx, the pl08x DMA data is already a pointer, but gets cast to resource_size_t so we can pass it as a resource, and it then gets converted back to a pointer. In contrast, the data we pass for s3c24xx is an index into a device specific table, and we artificially convert that into a pointer for the filter function. Signed-off-by:
Krzysztof Kozlowski <k.kozlowski@samsung.com> Signed-off-by:
Mark Brown <broonie@kernel.org> Signed-off-by:
-
Thierry Reding authored
BugLink: http://bugs.launchpad.net/bugs/1572722 commit 70a7fb80 upstream. Commit fa731ac7 ("regulator: core: avoid unused variable warning") introduced a subtle change in how supplies are locked. Where previously code was always locking the regulator of the current iteration, the new implementation only locks the regulator if it has a supply. For any given power tree that means that the root will never get locked. On the other hand the regulator_unlock_supply() will still release all the locks, which in turn causes the lock debugging code to warn about a mutex being unlocked which wasn't locked. Cc: Mark Brown <broonie@kernel.org> Cc: Arnd Bergmann <arnd@arndb.de> Fixes: Fixes: fa731ac7 ("regulator: core: avoid unused variable warning") Signed-off-by:
Thierry Reding <treding@nvidia.com> Signed-off-by:
-
Arnd Bergmann authored
BugLink: http://bugs.launchpad.net/bugs/1572722 commit fa731ac7 upstream. The second argument of the mutex_lock_nested() helper is only evaluated if CONFIG_DEBUG_LOCK_ALLOC is set. Otherwise we get this build warning for the new regulator_lock_supply function: drivers/regulator/core.c: In function 'regulator_lock_supply': drivers/regulator/core.c:142:6: warning: unused variable 'i' [-Wunused-variable] To avoid the warning, this restructures the code to make it both simpler and to move the 'i++' outside of the mutex_lock_nested call, where it is now always used and the variable is not flagged as unused. We had some discussion about changing mutex_lock_nested to an inline function, which would make the code do the right thing here, but in the end decided against it, in order to guarantee that mutex_lock_nested() does not introduced overhead without CONFIG_DEBUG_LOCK_ALLOC. Signed-off-by:
-
Sebastian Ott authored
BugLink: http://bugs.launchpad.net/bugs/1572291 Newer machines might use a different (larger) format for function measurement blocks. To ensure that we comply with the alignment requirement on these machines and prevent memory corruption (when firmware writes more data than we expect) add 16 padding bytes at the end of the fmb. Cc: stable@vger.kernel.org # v4.1+ Signed-off-by:
Sebastian Ott <sebott@linux.vnet.ibm.com> Signed-off-by:
Martin Schwidefsky <schwidefsky@de.ibm.com> (cherry picked from commit 9d89d9e6) Signed-off-by:
Andy Whitcroft <andy.whitcroft@canonical.com> Signed-off-by:
Kamal Mostafa <kamal@canonical.com>
-
Oliver Neukum authored
In case bind() works, but a later error forces bailing in probe() in error cases work and a timer may be scheduled. They must be killed. This fixes an error case related to the double free reported in http://www.spinics.net/lists/netdev/msg367669.html and needs to go on top of Linus' fix to cdc-ncm. Signed-off-by:
Oliver Neukum <ONeukum@suse.com> Signed-off-by:
David S. Miller <davem@davemloft.net> (cherry picked from commit 1666984c) CVE-2016-3951 BugLink: https://bugs.launchpad.net/bugs/1567191Signed-off-by:
Luis Henriques <luis.henriques@canonical.com> Signed-off-by:
-
Bjørn Mork authored
usbnet_link_change will call schedule_work and should be avoided if bind is failing. Otherwise we will end up with scheduled work referring to a netdev which has gone away. Instead of making the call conditional, we can just defer it to usbnet_probe, using the driver_info flag made for this purpose. Fixes: 8a34b0ae ("usbnet: cdc_ncm: apply usbnet_link_change") Reported-by:
Andrey Konovalov <andreyknvl@gmail.com> Suggested-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
Bjørn Mork <bjorn@mork.no> Signed-off-by:
-
Tim Gardner authored
Signed-off-by: -
Josh Boyer authored
BugLink: http://bugs.launchpad.net/bugs/1569924 If a user tells shim to not use the certs/hashes in the UEFI db variable for verification purposes, shim will set a UEFI variable called MokIgnoreDB. Have the uefi import code look for this and not import things from the db variable. Signed-off-by:
Josh Boyer <jwboyer@fedoraproject.org> Signed-off-by:
Stefan Bader <stefan.bader@canonical.com>
-
Josh Boyer authored
BugLink: http://bugs.launchpad.net/bugs/1569924 This adds an additional keyring that is used to store certificates that are blacklisted. This keyring is searched first when loading signed modules and if the module's certificate is found, it will refuse to load. This is useful in cases where third party certificates are used for module signing. Signed-off-by:
-
Tim Gardner authored
BugLink: http://bugs.launchpad.net/bugs/1569924Signed-off-by:
-
David Howells authored
BugLink: http://bugs.launchpad.net/bugs/1569924 Add KEY_ALLOC_BUILT_IN to convey that a key should have KEY_FLAG_BUILTIN set rather than setting it after the fact. Signed-off-by:
David Howells <dhowells@redhat.com> Acked-by:
Mimi Zohar <zohar@linux.vnet.ibm.com> (cherry picked from commit 5d2787cf) Signed-off-by:
-
Petko Manolov authored
BugLink: http://bugs.launchpad.net/bugs/1569924 This option creates IMA MOK and blacklist keyrings. IMA MOK is an intermediate keyring that sits between .system and .ima keyrings, effectively forming a simple CA hierarchy. To successfully import a key into .ima_mok it must be signed by a key which CA is in .system keyring. On turn any key that needs to go in .ima keyring must be signed by CA in either .system or .ima_mok keyrings. IMA MOK is empty at kernel boot. IMA blacklist keyring contains all revoked IMA keys. It is consulted before any other keyring. If the search is successful the requested operation is rejected and error is returned to the caller. Signed-off-by:
Petko Manolov <petkan@mip-labs.com> Signed-off-by:
-
Tim Gardner authored
BugLink: http://bugs.launchpad.net/bugs/1569924Signed-off-by:
-
Dave Howells authored
BugLink: http://bugs.launchpad.net/bugs/1569924 X.509 certificates are loaded into the specified keyring as asymmetric type keys. Signed-off-by:
-
Tim Gardner authored
BugLink: http://bugs.launchpad.net/bugs/1569924Signed-off-by:
-
Tadeusz Struk authored
BugLink: http://bugs.launchpad.net/bugs/1569924 This patch converts the module verification code to the new akcipher API. Signed-off-by:
Tadeusz Struk <tadeusz.struk@intel.com> Acked-by:
Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by:
-
Dave Howells authored
BugLink: http://bugs.launchpad.net/bugs/1569924 Add the data types that are used for containing hashes, keys and certificates for cryptographic verification. Bugzilla: N/A Upstream-status: Fedora mustard for now Signed-off-by:
-
Ard Biesheuvel authored
BugLink: http://bugs.launchpad.net/bugs/1569924 This exposes the firmware's implementation of EFI_RNG_PROTOCOL via a new function efi_get_random_bytes(). Reviewed-by:
Matt Fleming <matt@codeblueprint.co.uk> Signed-off-by:
Ard Biesheuvel <ard.biesheuvel@linaro.org> Signed-off-by:
Catalin Marinas <catalin.marinas@arm.com> (back ported from commit e4fbf476) Signed-off-by:
-
Peter Jones authored
BugLink: http://bugs.launchpad.net/bugs/1569924 This makes it much easier to hunt for typos in the GUID definitions. It also makes checkpatch complain less about efi.h GUID additions, so that if you add another one with the same style, checkpatch won't complain about it. Signed-off-by:
Peter Jones <pjones@redhat.com> Signed-off-by:
-
Robert Elliott authored
BugLink: http://bugs.launchpad.net/bugs/1569924 Add the NV memory attribute introduced in UEFI 2.5 and add a column for it in the types and attributes string used when printing the UEFI memory map. old: efi: mem61: [type=14 | | | | | | | |WB|WT|WC|UC] range=[0x0000000880000000-0x0000000c7fffffff) (16384MB) new: efi: mem61: [type=14 | | |NV| | | | | |WB|WT|WC|UC] range=[0x0000000880000000-0x0000000c7fffffff) (16384MB) Signed-off-by:
Robert Elliott <elliott@hpe.com> Signed-off-by:
Laszlo Ersek <lersek@redhat.com> Cc: Andy Lutomirski <luto@amacapital.net> Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Borislav Petkov <bp@alien8.de> Cc: Brian Gerst <brgerst@gmail.com> Cc: Dan Williams <dan.j.williams@intel.com> Cc: Denys Vlasenko <dvlasenk@redhat.com> Cc: H. Peter Anvin <hpa@zytor.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Ross Zwisler <ross.zwisler@linux.intel.com> Cc: Taku Izumi <izumi.taku@jp.fujitsu.com> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: linux-efi@vger.kernel.org Link: http://lkml.kernel.org/r/1454364428-494-13-git-send-email-matt@codeblueprint.co.ukSigned-off-by:
-
Ard Biesheuvel authored
BugLink: http://bugs.launchpad.net/bugs/1569924 The function efi_query_variable_store() may be invoked by efivar_entry_set_nonblocking(), which itself takes care to only call a non-blocking version of the SetVariable() runtime wrapper. However, efi_query_variable_store() may call the SetVariable() wrapper directly, as well as the wrapper for QueryVariableInfo(), both of which could deadlock in the same way we are trying to prevent by calling efivar_entry_set_nonblocking() in the first place. So instead, modify efi_query_variable_store() to use the non-blocking variants of QueryVariableInfo() (and give up rather than free up space if the available space is below EFI_MIN_RESERVE) if invoked with the 'nonblocking' argument set to true. Signed-off-by:
-
Ard Biesheuvel authored
BugLink: http://bugs.launchpad.net/bugs/1569924 This introduces a new runtime wrapper for the QueryVariableInfo() UEFI Runtime Service, which gives up immediately rather than spins on failure to grab the efi_runtime spinlock. This is required in the non-blocking path of the efi-pstore code. Signed-off-by:
-
Ard Biesheuvel authored
BugLink: http://bugs.launchpad.net/bugs/1569924 There is no need for a separate nonblocking prototype definition for the SetVariable() UEFI Runtime Service, since it is identical to the blocking version. Signed-off-by:
-
- 19 Apr, 2016 1 commit
-
-
Tim Gardner authored
Ignore: yes Signed-off-by:
-
- 18 Apr, 2016 4 commits
-
-
Tim Gardner authored
Signed-off-by: -
Tim Gardner authored
BugLink: http://bugs.launchpad.net/bugs/1571691 It would be much simpler if one could pass MOKSBState via a global variable, but the the EFI bits appear to be managed and linked a bit differently then a normal text section. Hence the shennanigans with boot_params.secure_boot. Signed-off-by:
-
Josh Boyer authored
BugLink: http://bugs.launchpad.net/bugs/1571691 git://pkgs.fedoraproject.org/rpms/kernel.git A user can manually tell the shim boot loader to disable validation of images it loads. When a user does this, it creates a UEFI variable called MokSBState that does not have the runtime attribute set. Given that the user explicitly disabled validation, we can honor that and not enable secure boot mode if that variable is set. Signed-off-by:
-
Josh Boyer authored
BugLink: http://bugs.launchpad.net/bugs/1571691 git://pkgs.fedoraproject.org/rpms/kernel.git Secure Boot stores a list of allowed certificates in the 'db' variable. This imports those certificates into the system trusted keyring. This allows for a third party signing certificate to be used in conjunction with signed modules. By importing the public certificate into the 'db' variable, a user can allow a module signed with that certificate to load. The shim UEFI bootloader has a similar certificate list stored in the 'MokListRT' variable. We import those as well. In the opposite case, Secure Boot maintains a list of disallowed certificates in the 'dbx' variable. We load those certificates into the newly introduced system blacklist keyring and forbid any module signed with those from loading. Signed-off-by:
-
