- 05 Dec, 2018 15 commits
-
-
Khalid Elmously authored
BugLink: https://bugs.launchpad.net/bugs/1806569Signed-off-by:
Khalid Elmously <khalid.elmously@canonical.com>
-
Siva Rebbagondla authored
BugLink: https://bugs.launchpad.net/bugs/1804360 When Association timeout happens and station tries to scan, observed below firmware assert. Root cause: When association starts, driver is sending station add peer notify to firmware but when Association timeout happens, driver is not sending station peer delete to Firmware. Hence, FW is going into DEEP SLEEP in associated state, which causes below Firmware assert. Fix: sending station delete peer notify when assoc timeout happens ...skipping... wlan0: authenticate with ac:a3:1e:a1:1e:85 wlan0: send auth to ac:a3:1e:a1:1e:85 (try 1/3) wlan0: authenticated wlan0: associate with ac:a3:1e:a1:1e:85 (try 1/3) wlan0: associate with ac:a3:1e:a1:1e:85 (try 2/3) wlan0: associate with ac:a3:1e:a1:1e:85 (try 3/3) wlan0: association with ac:a3:1e:a1:1e:85 timed out ven_rsi_91x: rsi_disable_ps: Cannot accept disable PS in PS_NONE state ven_rsi_91x: rsi_interrupt_handler: ==> FIRMWARE Assert <== ven_rsi_91x: rsi_interrupt_handler: Firmware Status is 0xa IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready Signed-off-by:
Siva Rebbagondla <siva.rebbagondla@redpinesignals.com> Acked-By:
Wen-chien Jesse Sung <jesse.sung@canonical.com> Acked-By:
Shrirang Bagul <shrirang.bagul@canonical.com> Signed-off-by:
Kleber Sacilotto de Souza <kleber.souza@canonical.com>
-
Thomas Gleixner authored
CVE-2018-12896 The posix timer overrun handling is broken because the forwarding functions can return a huge number of overruns which does not fit in an int. As a consequence timer_getoverrun(2) and siginfo::si_overrun can turn into random number generators. The k_clock::timer_forward() callbacks return a 64 bit value now. Make k_itimer::ti_overrun[_last] 64bit as well, so the kernel internal accounting is correct. 3Remove the temporary (int) casts. Add a helper function which clamps the overrun value returned to user space via timer_getoverrun(2) or siginfo::si_overrun limited to a positive value between 0 and INT_MAX. INT_MAX is an indicator for user space that the overrun value has been clamped. Reported-by:
Team OWL337 <icytxw@gmail.com> Signed-off-by:
Thomas Gleixner <tglx@linutronix.de> Acked-by:
John Stultz <john.stultz@linaro.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Michael Kerrisk <mtk.manpages@gmail.com> Link: https://lkml.kernel.org/r/20180626132705.018623573@linutronix.de (backported from commit 78c9c4df) [ kmously: Mostly context adjustments or adjusting for slightly refactored code. A cosmetic change from the original (changing '-1' to '-1LL') was dropped because it's not applicable ] Signed-off-by:
Tyler Hicks <tyhicks@canonical.com> Acked-by:
-
John Garry authored
Currently smatch warns of possible Spectre-V1 issue in ahci_led_store(): drivers/ata/libahci.c:1150 ahci_led_store() warn: potential spectre issue 'pp->em_priv' (local cap) Userspace controls @pmp from following callchain: em_message->store() ->ata_scsi_em_message_store() -->ap->ops->em_store() --->ahci_led_store() After the mask+shift @pmp is effectively an 8b value, which is used to index into an array of length 8, so sanitize the array index. Signed-off-by:
John Garry <john.garry@huawei.com> Signed-off-by:
Tejun Heo <tj@kernel.org> CVE-2017-5753 (cherry picked from commit fae2a637) Signed-off-by:
Juerg Haefliger <juergh@canonical.com> Acked-by:
Stefan Bader <stefan.bader@canonical.com> Acked-by:
-
Gustavo A. R. Silva authored
pdev_nr and rhport can be controlled by user-space, hence leading to a potential exploitation of the Spectre variant 1 vulnerability. This issue was detected with the help of Smatch: drivers/usb/usbip/vhci_sysfs.c:238 detach_store() warn: potential spectre issue 'vhcis' drivers/usb/usbip/vhci_sysfs.c:328 attach_store() warn: potential spectre issue 'vhcis' drivers/usb/usbip/vhci_sysfs.c:338 attach_store() warn: potential spectre issue 'vhci->vhci_hcd_ss->vdev' drivers/usb/usbip/vhci_sysfs.c:340 attach_store() warn: potential spectre issue 'vhci->vhci_hcd_hs->vdev' Fix this by sanitizing pdev_nr and rhport before using them to index vhcis and vhci->vhci_hcd_ss->vdev respectively. Notice that given that speculation windows are large, the policy is to kill the speculation on the first load and not worry if it can be completed with a dependent load/store [1]. [1] https://marc.info/?l=linux-kernel&m=152449131114778&w=2 Cc: stable@vger.kernel.org Signed-off-by:
Gustavo A. R. Silva <gustavo@embeddedor.com> Acked-by:
Shuah Khan (Samsung OSG) <shuah@kernel.org> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> CVE-2017-5753 (backported from commit a0d6ec88) [juergh: - Adjusted context. - Dropped the modification of valid_port() (not in Xenial) and modified the port checks in valid_args() and store_detach() instead().] Signed-off-by:
-
Takashi Iwai authored
As recently Smatch suggested, a few places in ALSA control core codes may expand the array directly from the user-space value with speculation: sound/core/control.c:1003 snd_ctl_elem_lock() warn: potential spectre issue 'kctl->vd' sound/core/control.c:1031 snd_ctl_elem_unlock() warn: potential spectre issue 'kctl->vd' sound/core/control.c:844 snd_ctl_elem_info() warn: potential spectre issue 'kctl->vd' sound/core/control.c:891 snd_ctl_elem_read() warn: potential spectre issue 'kctl->vd' sound/core/control.c:939 snd_ctl_elem_write() warn: potential spectre issue 'kctl->vd' Although all these seem doing only the first load without further reference, we may want to stay in a safer side, so hardening with array_index_nospec() would still make sense. In this patch, we put array_index_nospec() to the common snd_ctl_get_ioff*() helpers instead of each caller. These helpers are also referred from some drivers, too, and basically all usages are to calculate the array index from the user-space value, hence it's better to cover there. BugLink: https://marc.info/?l=linux-kernel&m=152411496503418&w=2Reported-by:
Dan Carpenter <dan.carpenter@oracle.com> Cc: <stable@vger.kernel.org> Signed-off-by:
Takashi Iwai <tiwai@suse.de> CVE-2017-5753 (backported from commit 088e861e) [juergh: Adjusted context.] Signed-off-by:
-
Takashi Iwai authored
As recently Smatch suggested, one place in RME9652 driver may expand the array directly from the user-space value with speculation: sound/pci/rme9652/rme9652.c:2074 snd_rme9652_channel_info() warn: potential spectre issue 'rme9652->channel_map' (local cap) This patch puts array_index_nospec() for hardening against it. BugLink: https://marc.info/?l=linux-kernel&m=152411496503418&w=2Reported-by:
-
Takashi Iwai authored
As recently Smatch suggested, a couple of places in HDSP MADI driver may expand the array directly from the user-space value with speculation: sound/pci/rme9652/hdspm.c:5717 snd_hdspm_channel_info() warn: potential spectre issue 'hdspm->channel_map_out' (local cap) sound/pci/rme9652/hdspm.c:5734 snd_hdspm_channel_info() warn: potential spectre issue 'hdspm->channel_map_in' (local cap) This patch puts array_index_nospec() for hardening against them. BugLink: https://marc.info/?l=linux-kernel&m=152411496503418&w=2Reported-by:
-
Takashi Iwai authored
As recently Smatch suggested, a couple of places in ASIHPI driver may expand the array directly from the user-space value with speculation: sound/pci/asihpi/hpimsginit.c:70 hpi_init_response() warn: potential spectre issue 'res_size' (local cap) sound/pci/asihpi/hpioctl.c:189 asihpi_hpi_ioctl() warn: potential spectre issue 'adapters' This patch puts array_index_nospec() for hardening against them. BugLink: https://marc.info/?l=linux-kernel&m=152411496503418&w=2Reported-by:
-
Takashi Iwai authored
As recently Smatch suggested, one place in OPL3 driver may expand the array directly from the user-space value with speculation: sound/drivers/opl3/opl3_synth.c:476 snd_opl3_set_voice() warn: potential spectre issue 'snd_opl3_regmap' This patch puts array_index_nospec() for hardening against it. BugLink: https://marc.info/?l=linux-kernel&m=152411496503418&w=2Reported-by:
-
Young_X authored
There is another cast from unsigned long to int which causes a bounds check to fail with specially crafted input. The value is then used as an index in the slot array in cdrom_slot_status(). This issue is similar to CVE-2018-16658 and CVE-2018-10940. Signed-off-by:
Young_X <YangX92@hotmail.com> Signed-off-by:
Jens Axboe <axboe@kernel.dk> CVE-2018-18710 (cherry picked from commit e4f3aa2e) Signed-off-by:
Seth Forshee <seth.forshee@canonical.com> Acked-by:
-
Darrick J. Wong authored
Kanda Motohiro reported that expanding a tiny xattr into a large xattr fails on XFS because we remove the tiny xattr from a shortform fork and then try to re-add it after converting the fork to extents format having not removed the ATTR_REPLACE flag. This fails because the attr is no longer present, causing a fs shutdown. This is derived from the patch in his bug report, but we really shouldn't ignore a nonzero retval from the remove call. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=199119 Reported-by: kanda.motohiro@gmail.com Reviewed-by:
Dave Chinner <dchinner@redhat.com> Reviewed-by:
Christoph Hellwig <hch@lst.de> Signed-off-by:
Darrick J. Wong <darrick.wong@oracle.com> CVE-2018-18690 (cherry picked from commit 7b38460d) Signed-off-by:
-
Laxman Dewangan authored
Use devm_pinctrl_register() for pin control registration and clean error path. Signed-off-by:
Laxman Dewangan <ldewangan@nvidia.com> Signed-off-by:
Linus Walleij <linus.walleij@linaro.org> CVE-2017-18174 (cherry picked from commit 251e22ab) Signed-off-by:
-
Laxman Dewangan authored
Add device managed APIs devm_pinctrl_register() and devm_pinctrl_unregister() for the APIs pinctrl_register() and pinctrl_unregister(). This helps in reducing code in error path and sometimes removal of .remove callback for driver unbind. Signed-off-by:
Philipp Zabel <p.zabel@pengutronix.de> Acked-by:
Bjorn Andersson <bjorn.andersson@linaro.org> Signed-off-by:
-
Khalid Elmously authored
Ignore: yes Signed-off-by:
-
- 13 Nov, 2018 25 commits
-
-
Khalid Elmously authored
Signed-off-by: -
Khalid Elmously authored
BugLink: https://bugs.launchpad.net/bugs/1802776Signed-off-by:
-
Eric W. Biederman authored
BugLink: https://launchpad.net/bugs/1789161 Jonathan Calmels from NVIDIA reported that he's able to bypass the mount visibility security check in place in the Linux kernel by using a combination of the unbindable property along with the private mount propagation option to allow a unprivileged user to see a path which was purposefully hidden by the root user. Reproducer: # Hide a path to all users using a tmpfs root@castiana:~# mount -t tmpfs tmpfs /sys/devices/ root@castiana:~# # As an unprivileged user, unshare user namespace and mount namespace stgraber@castiana:~$ unshare -U -m -r # Confirm the path is still not accessible root@castiana:~# ls /sys/devices/ # Make /sys recursively unbindable and private root@castiana:~# mount --make-runbindable /sys root@castiana:~# mount --make-private /sys # Recursively bind-mount the rest of /sys over to /mnnt root@castiana:~# mount --rbind /sys/ /mnt # Access our hidden /sys/device as an unprivileged user root@castiana:~# ls /mnt/devices/ breakpoint cpu cstate_core cstate_pkg i915 intel_pt isa kprobe LNXSYSTM:00 msr pci0000:00 platform pnp0 power software system tracepoint uncore_arb uncore_cbox_0 uncore_cbox_1 uprobe virtual Solve this by teaching copy_tree to fail if a mount turns out to be both unbindable and locked. Cc: stable@vger.kernel.org Fixes: 5ff9d8a6 ("vfs: Lock in place mounts from more privileged users") Reported-by:
Jonathan Calmels <jcalmels@nvidia.com> Signed-off-by:
"Eric W. Biederman" <ebiederm@xmission.com> (cherry picked from commit df7342b2) Signed-off-by:
Colin King <colin.king@canonical.com> Acked-by:
Thadeu Lima de Souza Cascardo <cascardo@canonical.com> Signed-off-by:
-
Eric W. Biederman authored
BugLink: https://launchpad.net/bugs/1789161 It was recently pointed out that the one instance of testing MNT_LOCKED outside of the namespace_sem is in ksys_umount. Fix that by adding a test inside of do_umount with namespace_sem and the mount_lock held. As it helps to fail fails the existing test is maintained with an additional comment pointing out that it may be racy because the locks are not held. Cc: stable@vger.kernel.org Reported-by:
Al Viro <viro@ZenIV.linux.org.uk> Fixes: 5ff9d8a6 ("vfs: Lock in place mounts from more privileged users") Signed-off-by:
-
Guilherme G. Piccoli authored
BugLink: https://bugs.launchpad.net/bugs/1797990 Recently was noticed in an HP GEN9 system that kdump couldn't succeed due to an irq storm coming from an Intel NIC, narrowed down to be lack of clearing the MSI/MSI-X enable bits during the kdump kernel boot. For that, we need an early quirk to manually turn off MSI/MSI-X for PCI devices - this was worked as an optional boot parameter in a (~subsequent~) previous patch. Problem is that in our test system, the Intel NICs were not present in any secondary bus under the first PCIe root complex, so they couldn't be reached by the recursion in check_dev_quirk(). Modern systems, specially with multi-processors and multiple NUMA nodes expose multiple root complexes, describing more than one PCI hierarchy domain. Currently the simple recursion present in the early-quirks code from x86 starts a descending recursion from bus 0000:00, and reach many other busses by navigating this hierarchy walking through the bridges. This is not enough in systems with more than one root complex/host bridge, since the recursion won't "traverse" to other root complexes by starting statically in 0000:00 (for more details, see [0]). This patch hence implements the full bus/device/function scan in early_quirks(), by checking all possible busses instead of using a recursion based on the first root bus or limiting the search scope to the first 32 busses (like it was done in the beginning [1]). [0] https://bugs.launchpad.net/bugs/1797990 [1] From historical perspective, early PCI scan dates back to BitKeeper, added by Andi Kleen's "[PATCH] APIC fixes for x86-64", on October/2003. It initially restricted the search to the first 32 busses and slots. Due to a potential bug found in Nvidia chipsets, the scan was changed to run only in the first root bus: see commit 8659c406 ("x86: only scan the root bus in early PCI quirks") Finally, secondary busses reachable from the 1st bus were re-added back by: commit 850c3210 ("x86/quirks: Reintroduce scanning of secondary buses") Reported-by:
Dan Streetman <ddstreet@canonical.com> Signed-off-by:
Guilherme G. Piccoli <gpiccoli@canonical.com> [mfo: v2: - gate the bus-scan differences with the cmdline option. - update changelog: subsequent/previous patch.] Signed-off-by:
Mauricio Faria de Oliveira <mfo@canonical.com> Acked-by:
-
Guilherme G. Piccoli authored
BugLink: https://bugs.launchpad.net/bugs/1797990 We observed a kdump failure in x86 that was narrowed down to MSI irq storm coming from a PCI network device. The bug manifests as a lack of progress in the boot process of kdump kernel, and a flood of kernel messages like: [...] [ 342.265294] do_IRQ: 0.155 No irq handler for vector [ 342.266916] do_IRQ: 0.155 No irq handler for vector [ 347.258422] do_IRQ: 14053260 callbacks suppressed [...] The root cause of the issue is that kexec process of the kdump kernel doesn't ensure PCI devices are reset or MSI capabilities are disabled, so a PCI adapter could produce a huge amount of irqs which would steal all the processing time for the CPU (specially since we usually restrict kdump kernel to use a single CPU only). This patch implements the kernel parameter "pci=clearmsi" to clear the MSI/MSI-X enable bits in the Message Control register for all PCI devices during early boot time, thus preventing potential issues in the kexec'ed kernel. PCI spec also supports/enforces this need (see PCI Local Bus spec sections 6.8.1.3 and 6.8.2.3). Suggested-by:
Gavin Shan <shan.gavin@linux.alibaba.com> Signed-off-by:
-
Guilherme G. Piccoli authored
BugLink: https://bugs.launchpad.net/bugs/1797990 This patch exports (and renames) the function find_cap() to be used in the early PCI quirk code, by the next patch. This is being moved out from AGP code to generic early-PCI code since it's not AGP-specific and can be used for any PCI device. No functional changes intended. Signed-off-by:
-
Arthur Kiyanovski authored
BugLink: http://bugs.launchpad.net/bugs/1802341 In ena_remove() we have the following stack call: ena_remove() unregister_netdev() ena_destroy_device() netif_carrier_off() Calling netif_carrier_off() causes linkwatch to try to handle the link change event on the already unregistered netdev, which leads to a read from an unreadable memory address. This patch switches the order of the two functions, so that netif_carrier_off() is called on a regiestered netdev. To accomplish this fix we also had to: 1. Remove the set bit ENA_FLAG_TRIGGER_RESET 2. Add a sanitiy check in ena_close() both to prevent double device reset (when calling unregister_netdev() ena_close is called, but the device was already deleted in ena_destroy_device()). 3. Set the admin_queue running state to false to avoid using it after device was reset (for example when calling ena_destroy_all_io_queues() right after ena_com_dev_reset() in ena_down) Finally, driver version is also updated. Change-Id: I3cc1aafe9cb3701a6eaee44e00add0e175c93148 Signed-off-by:
Arthur Kiyanovski <akiyano@amazon.com> Signed-off-by:
Kamal Mostafa <kamal@canonical.com> Acked-by:
-
Tomasz Nowicki authored
BugLink: https://bugs.launchpad.net/bugs/1797092 Implement pci_acpi_scan_root() and other arch-specific calls so ARM64 can use ACPI to setup and enumerate PCI buses. Use memory-mapped configuration space information from either the ACPI _CBA method or the MCFG table and the ECAM library and generic ECAM config accessor ops. Implement acpi_pci_bus_find_domain_nr() to retrieve the domain number from the acpi_pci_root structure. Implement pcibios_add_bus() and pcibios_remove_bus() to call acpi_pci_add_bus() and acpi_pci_remove_bus() for ACPI slot management and other configuration. Signed-off-by:
Tomasz Nowicki <tn@semihalf.com> Signed-off-by:
Jayachandran C <jchandra@broadcom.com> Signed-off-by:
Bjorn Helgaas <bhelgaas@google.com> Reviewed-by:
Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> (backported from commit 0cb0786b) [ dannf: Kconfig offset fixup ] Signed-off-by:
dann frazier <dann.frazier@canonical.com> Acked-by:
-
Tomasz Nowicki authored
BugLink: https://bugs.launchpad.net/bugs/1797092 To enable PCI legacy IRQs on platforms booting with ACPI, arch code should include ACPI-specific callbacks that parse and set-up the device IRQ number, equivalent to the DT boot path. Owing to the current ACPI core scan handlers implementation, ACPI PCI legacy IRQs bindings cannot be parsed at device add time, since that would trigger ACPI scan handlers ordering issues depending on how the ACPI tables are defined. To solve this problem and consolidate FW PCI legacy IRQs parsing in one single pcibios callback (pending final removal), this patch moves DT PCI IRQ parsing to the pcibios_alloc_irq() callback (called by PCI core code at driver probe time) and adds ACPI PCI legacy IRQs parsing to the same callback too, so that FW PCI legacy IRQs parsing is confined in one single arch callback that can be easily removed when code parsing PCI legacy IRQs is consolidated and moved to core PCI code. Suggested-by:
-
Tomasz Nowicki authored
BugLink: https://bugs.launchpad.net/bugs/1797092 Extend pci_bus_find_domain_nr() so it can find the domain from either: - ACPI, via the new acpi_pci_bus_find_domain_nr() interface, or - DT, via of_pci_bus_find_domain_nr() Note that this is only used for CONFIG_PCI_DOMAINS_GENERIC=y, so it does not affect x86 or ia64. [bhelgaas: changelog] Signed-off-by:
-
Tomasz Nowicki authored
BugLink: https://bugs.launchpad.net/bugs/1797092 pci_bus_find_domain_nr() retrieves the host bridge domain number in a DT-specific way. Rename it to of_pci_bus_find_domain_nr() to reflect that, so we can add a corresponding function for ACPI. [bhelgaas: changelog] Signed-off-by:
-
Tomasz Nowicki authored
BugLink: https://bugs.launchpad.net/bugs/1797092 Instead of assigning bus->domain_nr inside pci_bus_assign_domain_nr(), return the domain and let the caller do the assignment. Rename pci_bus_assign_domain_nr() to pci_bus_find_domain_nr() to reflect this. No functional change intended. [bhelgaas: changelog] Signed-off-by:
-
Tomasz Nowicki authored
BugLink: https://bugs.launchpad.net/bugs/1797092 On ACPI systems that support memory-mapped config space access, i.e., ECAM, the PCI Firmware Specification says the OS can learn where the ECAM space is from either: - the static MCFG table (for non-hotpluggable bridges), or - the _CBA method (for hotpluggable bridges) The current MCFG table handling code cannot be easily generalized owing to x86-specific quirks, which makes it hard to reuse on other architectures. Implement generic MCFG handling from scratch, including: - Simple MCFG table parsing (via pci_mmcfg_late_init() as in current x86) - MCFG region lookup for a (domain, bus_start, bus_end) tuple [bhelgaas: changelog] Signed-off-by:
-
dann frazier authored
BugLink: https://bugs.launchpad.net/bugs/1797092Signed-off-by:
-
Jayachandran C authored
BugLink: https://bugs.launchpad.net/bugs/1797092 On platforms with memory-mapped I/O ports, such as ia64 and ARM64, we have to map the memory region and coordinate it with the arch's I/O port accessors. For ia64, we do this in arch code because it supports both dense (1 byte per I/O port) and sparse (1024 bytes per I/O port) memory mapping. For arm64, we only support dense mappings, which we can do in the generic code with pci_register_io_range() and pci_remap_iospace(). Add acpi_pci_root_remap_iospace() to remap dense memory-mapped I/O port space when adding a bridge, and call pci_unmap_iospace() to release the space when removing the bridge. [bhelgaas: changelog, move #ifdef inside acpi_pci_root_remap_iospace()] Signed-off-by:
Sinan Kaya <okaya@codeaurora.org> [Tomasz: merged in Sinan's patch to unmap IO resources properly, updated changelog] Signed-off-by:
-
Sinan Kaya authored
BugLink: https://bugs.launchpad.net/bugs/1797092 Add pci_unmap_iospace() to undo what pci_remap_iospace() did. This is needed to support hotplug removal of host bridges that use pci_remap_iospace(). [bhelgaas: changelog] Signed-off-by:
-
Jayachandran C authored
BugLink: https://bugs.launchpad.net/bugs/1797092 Add a parent device field to struct pci_config_window. The parent is not saved now, but will be useful to save it in some cases. For ACPI on ARM64, it can be used to setup ACPI companion and domain. Since the parent dev is in struct pci_config_window now, we need not pass it to the init function as a separate argument. Signed-off-by:
-
Jayachandran C authored
BugLink: https://bugs.launchpad.net/bugs/1797092 This header will be used from arch/arm64 for ACPI PCI implementation so it needs to be moved out of drivers/pci. Update users of the header file to use the new name. No functional changes. Signed-off-by:
-
Tomasz Nowicki authored
BugLink: https://bugs.launchpad.net/bugs/1797092 No functional changes in this patch. PCI I/O space mapping code does not depend on OF; therefore it can be moved to PCI core code. This way we will be able to use it, e.g., in ACPI PCI code. Suggested-by:
-
Jayachandran C authored
BugLink: https://bugs.launchpad.net/bugs/1797092 Use functions provided by drivers/pci/ecam.h for mapping the config space in drivers/pci/host/pci-host-common.c, and update its users to use 'struct pci_config_window' and 'struct pci_ecam_ops'. The changes are mostly to use 'struct pci_config_window' in place of 'struct gen_pci'. Some of the fields of gen_pci were only used temporarily and can be eliminated by using local variables or function arguments, these are not carried over to struct pci_config_window. pci-thunder-ecam.c and pci-thunder-pem.c are the only users of the pci_host_common_probe function and the gen_pci structure; these have been updated to use the new API as well. The patch does not introduce any functional changes other than a very minor one: with the new code, on 64-bit platforms, we do just a single ioremap for the whole config space. Signed-off-by:
-
Jayachandran C authored
BugLink: https://bugs.launchpad.net/bugs/1797092 Add config option PCI_ECAM and file drivers/pci/ecam.c to provide generic functions for accessing memory-mapped PCI config space. The API is defined in drivers/pci/ecam.h and is written to replace the API in drivers/pci/host/pci-host-common.h. The file defines a new 'struct pci_config_window' to hold the information related to a PCI config area and its mapping. This structure is expected to be used as sysdata for controllers that have ECAM based mapping. Helper functions are provided to setup the mapping, free the mapping and to implement the map_bus method in 'struct pci_ops' Signed-off-by:
-
dann frazier authored
BugLink: https://bugs.launchpad.net/bugs/1797092Signed-off-by:
-
Sai Praneeth authored
BugLink: https://launchpad.net/bugs/1786139 Future Intel processors will support "Enhanced IBRS" which is an "always on" mode i.e. IBRS bit in SPEC_CTRL MSR is enabled once and never disabled. From the specification [1]: "With enhanced IBRS, the predicted targets of indirect branches executed cannot be controlled by software that was executed in a less privileged predictor mode or on another logical processor. As a result, software operating on a processor with enhanced IBRS need not use WRMSR to set IA32_SPEC_CTRL.IBRS after every transition to a more privileged predictor mode. Software can isolate predictor modes effectively simply by setting the bit once. Software need not disable enhanced IBRS prior to entering a sleep state such as MWAIT or HLT." If Enhanced IBRS is supported by the processor then use it as the preferred spectre v2 mitigation mechanism instead of Retpoline. Intel's Retpoline white paper [2] states: "Retpoline is known to be an effective branch target injection (Spectre variant 2) mitigation on Intel processors belonging to family 6 (enumerated by the CPUID instruction) that do not have support for enhanced IBRS. On processors that support enhanced IBRS, it should be used for mitigation instead of retpoline." The reason why Enhanced IBRS is the recommended mitigation on processors which support it is that these processors also support CET which provides a defense against ROP attacks. Retpoline is very similar to ROP techniques and might trigger false positives in the CET defense. If Enhanced IBRS is selected as the mitigation technique for spectre v2, the IBRS bit in SPEC_CTRL MSR is set once at boot time and never cleared. Kernel also has to make sure that IBRS bit remains set after VMEXIT because the guest might have cleared the bit. This is already covered by the existing x86_spec_ctrl_set_guest() and x86_spec_ctrl_restore_host() speculation control functions. Enhanced IBRS still requires IBPB for full mitigation. [1] Speculative-Execution-Side-Channel-Mitigations.pdf [2] Retpoline-A-Branch-Target-Injection-Mitigation.pdf Both documents are available at: https://bugzilla.kernel.org/show_bug.cgi?id=199511Originally-by:
David Woodhouse <dwmw@amazon.co.uk> Signed-off-by:
Sai Praneeth Prakhya <sai.praneeth.prakhya@intel.com> Signed-off-by:
-
Jiang Biao authored
BugLink: https://launchpad.net/bugs/1786139 SPECTRE_V2_IBRS in enum spectre_v2_mitigation is never used. Remove it. Signed-off-by:
Jiang Biao <jiang.biao2@zte.com.cn> Signed-off-by:
-
