Select Git revision
Search by author
- Any Author
- authors
-
Angus Ainslie
angus.ainslie
-
Eric Kuzmenko
eric.kuzmenko
-
Evangelos Ribeiro Tzaras
evangelos.tzaras
-
Francois Techene
francois.techene
-
Guido Gunther
guido.gunther
-
JC Staudt
jcstaudt
-
Jonathon Hall
jonathon.hall
-
Julian Sparber
julian.sparber
-
Martin Kepplinger
martin.kepplinger
-
Mohammed Sadiq
mohammed.sadiq
-
Richard Kolla
richard.kolla
-
Sam Hewitt sam.hewitt
-
Sebastian Krzyszkowiak
sebastian.krzyszkowiak
- Jun 17, 2020
-
-
Ryusuke Konishi authored
commit 8301c719 upstream. After commit c3aab9a0 ("mm/filemap.c: don't initiate writeback if mapping has no dirty pages"), the following null pointer dereference has been reported on nilfs2: BUG: kernel NULL pointer dereference, address: 00000000000000a8 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: 0000 [#1] SMP PTI ... RIP: 0010:percpu_counter_add_batch+0xa/0x60 ... Call Trace: __test_set_page_writeback+0x2d3/0x330 nilfs_segctor_do_construct+0x10d3/0x2110 [nilfs2] nilfs_segctor_construct+0x168/0x260 [nilfs2] nilfs_segctor_thread+0x127/0x3b0 [nilfs2] kthread+0xf8/0x130 ... This crash turned out to be caused by set_page_writeback() call for segment summary buffers at nilfs_segctor_prepare_write(). set_page_writeback() can call inc_wb_stat(inode_to_wb(inode), WB_WRITEBACK) where inode_to_wb(inode) is NULL if the inode of underlying block device does not have an associated wb. This fixes the issue by calling inode_attach_wb() in advance to ensure to associate the bdev inode with its wb. Fixes: c3aab9a0 ("mm/filemap.c: don't initiate writeback if mapping has no dirty pages") Reported-by:
-
Dave Rodgman authored
commit b5265c81 upstream. In some rare cases, for input data over 32 KB, lzo-rle could encode two different inputs to the same compressed representation, so that decompression is then ambiguous (i.e. data may be corrupted - although zram is not affected because it operates over 4 KB pages). This modifies the compressor without changing the decompressor or the bitstream format, such that: - there is no change to how data produced by the old compressor is decompressed - an old decompressor will correctly decode data from the updated compressor - performance and compression ratio are not affected - we avoid introducing a new bitstream format In testing over 12.8M real-world files totalling 903 GB, three files were affected by this bug. I also constructed 37M semi-random 64 KB files totalling 2.27 TB, and saw no affected files. Finally I tested over files constructed to contain each of the ~1024 possible bad input sequences; for all of these cases, updated lzo-rle worked correctly. There is no significant impact to performance or compression ratio. Signed-off-by:
-
Nick Desaulniers authored
commit a194c33f upstream. Will reported a UBSAN warning: UBSAN: null-ptr-deref in arch/arm64/kernel/smp.c:596:6 member access within null pointer of type 'struct acpi_madt_generic_interrupt' CPU: 0 PID: 0 Comm: swapper Not tainted 5.7.0-rc6-00124-g96bc42ff0a82 #1 Call trace: dump_backtrace+0x0/0x384 show_stack+0x28/0x38 dump_stack+0xec/0x174 handle_null_ptr_deref+0x134/0x174 __ubsan_handle_type_mismatch_v1+0x84/0xa4 acpi_parse_gic_cpu_interface+0x60/0xe8 acpi_parse_entries_array+0x288/0x498 acpi_table_parse_entries_array+0x178/0x1b4 acpi_table_parse_madt+0xa4/0x110 acpi_parse_and_init_cpus+0x38/0x100 smp_init_cpus+0x74/0x258 setup_arch+0x350/0x3ec start_kernel+0x98/0x6f4 This is from the use of the ACPI_OFFSET in arch/arm64/include/asm/acpi.h. Replace its use with offsetof from include/linux/stddef.h which should implement the same logic using __builtin_offsetof, so that UBSAN wont warn. Reported-by:
-
Rafael J. Wysocki authored
commit 956ad9d9 upstream. As recently reported, some platforms provide a list of power resources for device power state D3hot, through the _PR3 object, but they do not provide a list of power resources for device power state D0. Among other things, this causes acpi_device_get_power() to return D3hot as the current state of the device in question if all of the D3hot power resources are "on", because it sees the power_resources flag set and calls acpi_power_get_inferred_state() which finds that D3hot is the shallowest power state with all of the associated power resources turned "on", so that's what it returns. Moreover, that value takes precedence over the acpi_dev_pm_explicit_get() return value, because it means a deeper power state. The device may very well be in D0 physically at that point, however. Moreover, the presence of _PR3 without _PR0 for a given device means that only one D3-level power state can be supported by it. Namely, because there are no power resources to turn "off" when transitioning the device from D0 into D3cold (which should be supported since _PR3 is present), the evaluation of _PS3 should be sufficient to put it straight into D3cold, but this means that the effect of turning "on" the _PR3 power resources is unclear, so it is better to avoid doing that altogether. Consequently, there is no practical way do distinguish D3cold from D3hot for the device in question and the power states of it can be labeled so that D3hot is the deepest supported one (and Linux assumes that putting a device into D3hot via ACPI may cause power to be removed from it anyway, for legacy reasons). To work around the problem described above modify the ACPI enumeration of devices so that power resources are only used for device power management if the list of D0 power resources is not empty and make it mart D3cold as supported only if that is the case and the D3hot list of power resources is not empty too. Fixes: ef85bdbe ("ACPI / scan: Consolidate extraction of power resources lists") Link: https://bugzilla.kernel.org/show_bug.cgi?id=205057 Link: https://lore.kernel.org/linux-acpi/20200603194659.185757-1-hdegoede@redhat.com/ Reported-by:
-
Ard Biesheuvel authored
commit ea6f3af4 upstream. Per the ACPI spec, interrupts in the range [0, 255] may be handled in AML using individual methods whose naming is based on the format _Exx or _Lxx, where xx is the hex representation of the interrupt index. Add support for this missing feature to our ACPI GED driver. Cc: v4.9+ <stable@vger.kernel.org> # v4.9+ Signed-off-by:
-
Qiushi Wu authored
commit 4d8be4bc upstream. kobject_init_and_add() takes reference even when it fails. If this function returns an error, kobject_put() must be called to properly clean up the memory associated with the object. Previous commit "b8eb7183" fixed a similar problem. Fixes: 158c998e ("ACPI / CPPC: add sysfs support to compute delivered performance") Signed-off-by:
-
Qiushi Wu authored
commit 6e6c2528 upstream. kobject_init_and_add() takes reference even when it fails. Thus, when kobject_init_and_add() returns an error, kobject_put() must be called to properly clean up the kobject. Fixes: 3f8055c3 ("ACPI / hotplug: Introduce user space interface for hotplug profiles") Signed-off-by:
-
Kai-Heng Feng authored
commit 0c5086f5 upstream. The HP Thunderbolt Dock has two separate USB devices, one is for speaker and one is for headset. Add names for them so userspace can apply UCM settings. Signed-off-by:
-
Takashi Iwai authored
commit 862b2509 upstream. When a USB-audio interface gets runtime-suspended via auto-pm feature, the driver suspends all functionality and increment chip->num_suspended_intf. Later on, when the system gets suspended to S3, the driver increments chip->num_suspended_intf again, skips the device changes, and sets the card power state to SNDRV_CTL_POWER_D3hot. In return, when the system gets resumed from S3, the resume callback decrements chip->num_suspended_intf. Since this refcount is still not zero (it's been runtime-suspended), the whole resume is skipped. But there is a small pitfall here. The problem is that the driver doesn't restore the card power state after this resume call, leaving it as SNDRV_CTL_POWER_D3hot. So, even after the system resume finishes, the card instance still appears as if it were system-suspended, and this confuses many ioctl accesses that are blocked unexpectedly. In details, we have two issues behind the scene: one is that the card power state is changed only when the refcount becomes zero, and another is that the prior auto-suspend check is kept in a boolean flag. Although the latter problem is almost negligible since the auto-pm feature is imposed only on the primary interface, but this can be a potential problem on the devices with multiple interfaces. This patch addresses those issues by the following: - Replace chip->autosuspended boolean flag with chip->system_suspend counter - At the first system-suspend, chip->num_suspended_intf is recorded to chip->system_suspend - At system-resume, the card power state is restored when the chip->num_suspended_intf refcount reaches to chip->system_suspend, i.e. the state returns to the auto-suspended Also, the patch fixes yet another hidden problem by the code refactoring along with the fixes above: namely, when some resume procedure failed, the driver left chip->num_suspended_intf that was already decreased, and it might lead to the refcount unbalance. In the new code, the refcount decrement is done after the whole resume procedure, and the problem is avoided as well. Fixes: 0662292a ("ALSA: usb-audio: Handle normal and auto-suspend equally") Reported-and-tested-by:
-
Michał Mirosław authored
commit e18035cf upstream. Add and use snd_pcm_stream_lock_nested() in snd_pcm_link/unlink implementation. The code is fine, but generates a lockdep complaint: ============================================ WARNING: possible recursive locking detected 5.7.1mq+ #381 Tainted: G O -------------------------------------------- pulseaudio/4180 is trying to acquire lock: ffff888402d6f508 (&group->lock){-...}-{2:2}, at: snd_pcm_common_ioctl+0xda8/0xee0 [snd_pcm] but task is already holding lock: ffff8883f7a8cf18 (&group->lock){-...}-{2:2}, at: snd_pcm_common_ioctl+0xe4e/0xee0 [snd_pcm] other info that might help us debug this: Possible unsafe locking scenario: CPU0 ---- lock(&group->lock); lock(&group->lock); *** DEADLOCK *** May be due to missing lock nesting notation 2 locks held by pulseaudio/4180: #0: ffffffffa1a05190 (snd_pcm_link_rwsem){++++}-{3:3}, at: snd_pcm_common_ioctl+0xca0/0xee0 [snd_pcm] #1: ffff8883f7a8cf18 (&group->lock){-...}-{2:2}, at: snd_pcm_common_ioctl+0xe4e/0xee0 [snd_pcm] [...] Cc: stable@vger.kernel.org Fixes: f57f3df0 ("ALSA: pcm: More fine-grained PCM link locking") Signed-off-by:
-
Michał Mirosław authored
commit 951e2736 upstream. Prevent SNDRV_PCM_IOCTL_LINK linking stream to itself - the code can't handle it. Fixed commit is not where bug was introduced, but changes the context significantly. Cc: stable@vger.kernel.org Fixes: 0888c321 ("pcm_native: switch to fdget()/fdput()") Signed-off-by:
-
Hui Wang authored
commit 573fcbfd upstream. A couple of Lenovo ThinkCentre machines all have 2 front mics and they use the same codec alc623 and have the same pin config, so add a pintbl entry for those machines to apply the fixup ALC283_FIXUP_HEADSET_MIC. Cc: <stable@vger.kernel.org> Signed-off-by:
-
Takashi Sakamoto authored
commit f4588cc4 upstream. In the latter models of RME Fireface series, device start to transfer packets several dozens of milliseconds. On the other hand, ALSA fireface driver starts IR context 2 milliseconds after the start. This results in loss to handle incoming packets on the context. This commit changes to start IR context immediately instead of postponement. For Fireface 800, this affects nothing because the device transfer packets 100 milliseconds or so after the start and this is within wait timeout. Cc: <stable@vger.kernel.org> Fixes: acfedcbe ("ALSA: firewire-lib: postpone to start IR context") Signed-off-by:
-
Takashi Sakamoto authored
commit bbd6aac3 upstream. 128000 and 192000 are congruence modulo 32000, thus it's wrong to distinguish them as multiple of 32000 and 48000 by modulo 32000 at first. Additionally, used condition statement to detect quadruple speed can cause missing bit flag. Furthermore, counter to ensure the configuration is wrong and it causes false positive. This commit fixes the above three bugs. Cc: <stable@vger.kernel.org> Fixes: 60aec494 ("ALSA: fireface: support allocate_resources operation in latter protocol") Signed-off-by:
-
Hersen Wu authored
commit 27a7c670 upstream. dp/hdmi ati hda is not shown in audio settings [ rearranged to a more appropriate place per device number order -- tiwai ] Signed-off-by:
-
Chuhong Yuan authored
commit d9b8fbf1 upstream. snd_es968_pnp_detect() misses a snd_card_free() in a failed path. Add the missed function call to fix it. Fixes: a20971b2 ("ALSA: Merge es1688 and es968 drivers") Signed-off-by:
-
Fabio Estevam authored
commit e56d48e9 upstream. Currently when running the samples/watchdog/watchdog-simple.c application and forcing a kernel crash by doing: # ./watchdog-simple & # echo c > /proc/sysrq-trigger The system does not reboot as expected. Fix it by calling imx_sc_wdt_set_timeout() to configure the i.MX8QXP watchdog with a proper timeout. Cc: <stable@vger.kernel.org> Fixes: 986857ac ("watchdog: imx_sc: Add i.MX system controller watchdog support") Reported-by:
-
Andy Shevchenko authored
commit 8f065ace upstream. The commit a3cb39d2 ("serial: core: Allow detach and attach serial device for console") changed a bit logic behind lock initialization since for most of the console driver it's supposed to have lock already initialized even if console is not enabled. However, it's not the case for Freescale IMX console. Initialize lock explicitly in the ->probe(). Note, there is still an open question should or shouldn't not this driver register console properly. Fixes: a3cb39d2 ("serial: core: Allow detach and attach serial device for console") Reported-by:
-
Steve French authored
commit 7866c177 upstream. Missing the final 's' in "max_channels" mount option when displayed in /proc/mounts (or by mount command) CC: Stable <stable@vger.kernel.org> Signed-off-by:
-
Namjae Jeon authored
commit ebf57440 upstream. Some of tests in xfstests failed with cifsd kernel server since commit e80ddeb2. cifsd kernel server validates credit charge from client by calculating it base on max((InputCount + OutputCount) and (MaxInputResponse + MaxOutputResponse)) according to specification. MS-SMB2 specification describe credit charge calculation of smb2 ioctl : If Connection.SupportsMultiCredit is TRUE, the server MUST validate CreditCharge based on the maximum of (InputCount + OutputCount) and (MaxInputResponse + MaxOutputResponse), as specified in section 3.3.5.2.5. If the validation fails, it MUST fail the IOCTL request with STATUS_INVALID_PARAMETER. This patch add indatalen that can be a non-zero value to calculation of credit charge in SMB2_ioctl_init(). Fixes: e80ddeb2 ("smb3: fix incorrect number of credits when ioctl MaxOutputResponse > 64K") Cc: Stable <stable@vger.kernel.org> Reviewed-by:
-
Steve French authored
commit e80ddeb2 upstream. We were not checking to see if ioctl requests asked for more than 64K (ie when CIFSMaxBufSize was > 64K) so when setting larger CIFSMaxBufSize then ioctls would fail with invalid parameter errors. When requests ask for more than 64K in MaxOutputResponse then we need to ask for more than 1 credit. Signed-off-by:
-
Ard Biesheuvel authored
commit d8bd8c6e upstream. The documentation provided by kobject_init_and_add() clearly spells out the need to call kobject_put() on the kobject if an error is returned. Add this missing call to the error path. Cc: <stable@vger.kernel.org> Reported-by:
-
Jens Axboe authored
commit c5b85625 upstream. We can assume that O_NONBLOCK is always honored, even if we don't have a ->read/write_iter() for the file type. Also unify the read/write checking for allowing async punt, having the write side factoring in the REQ_F_NOWAIT flag as well. Cc: stable@vger.kernel.org Fixes: 490e8967 ("io_uring: only force async punt if poll based retry can't handle it") Signed-off-by:
-
Denis Efremov authored
commit a8c73c1a upstream. Use kvfree() to free the pages and vmas, since they are allocated by kvmalloc_array() in a loop. Fixes: d4ef6475 ("io_uring: avoid page allocation warnings") Signed-off-by:
-
Jens Axboe authored
commit dddb3e26 upstream. We already have the buffer selected, but we should set the iter list again. Cc: stable@vger.kernel.org # v5.7 Signed-off-by:
-
Pavel Begunkov authored
commit 4518a3cc upstream. In io_uring_cancel_files(), after refcount_sub_and_test() leaves 0 req->refs, it calls io_put_req(), which would also put a ref. Call io_free_req() instead. Cc: stable@vger.kernel.org Fixes: 2ca10259 ("io_uring: prune request from overflow list on flush") Signed-off-by:
-
Pavel Dobias authored
commit 8ba4dc3c upstream. The xmax values for Master Playback Volume and Mic Boost Capture Volume are specified incorrectly (one greater) which results in the wrong dB gain being shown to the user in the case of Master Playback Volume. Signed-off-by:
-
Dan Murphy authored
commit be8499c4 upstream. Fix the mic gain registers for channels 2-4. The incorret register was being set as it was touching the CH1 config registers. Fixes: 37bde5acf040 ("ASoC: tlv320adcx140: Add the tlv320adcx140 codec driver family") Signed-off-by:
-
Christophe Leroy authored
commit b00ff6d8 upstream. In order to properly display information regardless of the page size, it is necessary to take into account real page size. Fixes: cabe8138 ("powerpc: dump as a single line areas mapping a single physical page.") Cc: stable@vger.kernel.org Signed-off-by:
-
Eiichi Tsukata authored
commit e649b3f0 upstream. Commit b1394e74 ("KVM: x86: fix APIC page invalidation") tried to fix inappropriate APIC page invalidation by re-introducing arch specific kvm_arch_mmu_notifier_invalidate_range() and calling it from kvm_mmu_notifier_invalidate_range_start. However, the patch left a possible race where the VMCS APIC address cache is updated *before* it is unmapped: (Invalidator) kvm_mmu_notifier_invalidate_range_start() (Invalidator) kvm_make_all_cpus_request(kvm, KVM_REQ_APIC_PAGE_RELOAD) (KVM VCPU) vcpu_enter_guest() (KVM VCPU) kvm_vcpu_reload_apic_access_page() (Invalidator) actually unmap page Because of the above race, there can be a mismatch between the host physical address stored in the APIC_ACCESS_PAGE VMCS field and the host physical address stored in the EPT entry for the APIC GPA (0xfee0000). When this happens, the processor will not trap APIC accesses, and will instead show the raw contents of the APIC-access page. Because Windows OS periodically checks for unexpected modifications to the LAPIC register, this will show up as a BSOD crash with BugCheck CRITICAL_STRUCTURE_CORRUPTION (109) we are currently seeing in https://bugzilla.redhat.com/show_bug.cgi?id=1751017. The root cause of the issue is that kvm_arch_mmu_notifier_invalidate_range() cannot guarantee that no additional references are taken to the pages in the range before kvm_mmu_notifier_invalidate_range_end(). Fortunately, this case is supported by the MMU notifier API, as documented in include/linux/mmu_notifier.h: * If the subsystem * can't guarantee that no additional references are taken to * the pages in the range, it has to implement the * invalidate_range() notifier to remove any references taken * after invalidate_range_start(). The fix therefore is to reload the APIC-access page field in the VMCS from kvm_mmu_notifier_invalidate_range() instead of ..._range_start(). Cc: stable@vger.kernel.org Fixes: b1394e74 ("KVM: x86: fix APIC page invalidation") Fixes: https://bugzilla.kernel.org/show_bug.cgi?id=197951 Signed-off-by:
-
Felipe Franciosi authored
commit 384dea1c upstream. When userspace configures KVM_GUESTDBG_SINGLESTEP, KVM will manage the presence of X86_EFLAGS_TF via kvm_set/get_rflags on vcpus. The actual rflag bit is therefore hidden from callers. That includes init_emulate_ctxt() which uses the value returned from kvm_get_flags() to set ctxt->tf. As a result, x86_emulate_instruction() will skip a single step, leaving singlestep_rip stale and not returning to userspace. This resolves the issue by observing the vcpu guest_debug configuration alongside ctxt->tf in x86_emulate_instruction(), performing the single step if set. Cc: stable@vger.kernel.org Signed-off-by:
-
Sean Christopherson authored
commit 6129ed87 upstream. Set the mmio_value to '0' instead of simply clearing the present bit to squash a benign warning in kvm_mmu_set_mmio_spte_mask() that complains about the mmio_value overlapping the lower GFN mask on systems with 52 bits of PA space. Opportunistically clean up the code and comments. Cc: stable@vger.kernel.org Fixes: d43e2675 ("KVM: x86: only do L1TF workaround on affected processors") Signed-off-by:
-
Maxim Levitsky authored
commit 0abcc8f6 upstream. Even though we might not allow the guest to use WAITPKG's new instructions, we should tell KVM that the feature is supported by the host CPU. Note that vmx_waitpkg_supported checks that WAITPKG _can_ be set in secondary execution controls as specified by VMX capability MSR, rather that we actually enable it for a guest. Cc: stable@vger.kernel.org Fixes: e69e72fa ("KVM: x86: Add support for user wait instructions") Suggested-by:
-
Paolo Bonzini authored
commit df2a69af upstream. The migration functionality was left incomplete in commit 5ef8acbd ("KVM: nVMX: Emulate MTF when performing instruction emulation", 2020-02-23), fix it. Fixes: 5ef8acbd ("KVM: nVMX: Emulate MTF when performing instruction emulation") Cc: stable@vger.kernel.org Reviewed-by:
-
Maxim Levitsky authored
commit f4cfcd2d upstream. This msr is only available when the host supports WAITPKG feature. This breaks a nested guest, if the L1 hypervisor is set to ignore unknown msrs, because the only other safety check that the kernel does is that it attempts to read the msr and rejects it if it gets an exception. Cc: stable@vger.kernel.org Fixes: 6e3ba4ab ("KVM: vmx: Emulate MSR IA32_UMWAIT_CONTROL") Signed-off-by:
-
Kan Liang authored
commit 0813c405 upstream. The mask in the extra_regs for Intel Tremont need to be extended to allow more defined bits. "Outstanding Requests" (bit 63) is only available on MSR_OFFCORE_RSP0; Fixes: 6daeb873 ("perf/x86/intel: Add Tremont core PMU support") Reported-by:
-
Thomas Gleixner authored
commit 7778d841 upstream. The conversion of x86 VDSO to the generic clock mode storage broke the paravirt and hyperv clocksource logic. These clock sources have their own internal sequence counter to validate the clocksource at the point of reading it. This is necessary because the hypervisor can invalidate the clocksource asynchronously so a check during the VDSO data update is not sufficient. If the internal check during read invalidates the clocksource the read return U64_MAX. The original code checked this efficiently by testing whether the result (casted to signed) is negative, i.e. bit 63 is set. This was done that way because an extra indicator for the validity had more overhead. The conversion broke this check because the check was replaced by a check for a valid VDSO clock mode. The wreckage manifests itself when the paravirt clock is installed as a valid VDSO clock and during runtime invalidated by the hypervisor, e.g. after a host suspend/resume cycle. After the invalidation the read function returns U64_MAX which is used as cycles and makes the clock jump by ~2200 seconds, and become stale until the 2200 seconds have elapsed where it starts to jump again. The period of this effect depends on the shift/mult pair of the clocksource and the jumps and staleness are an artifact of undefined but reproducible behaviour of math overflow. Implement an x86 version of the new vdso_cycles_ok() inline which adds this check back and a variant of vdso_clocksource_ok() which lets the compiler optimize it out to avoid the extra conditional. That's suboptimal when the system does not have a VDSO capable clocksource, but that's not the case which is optimized for. Fixes: 5d51bee7 ("clocksource: Add common vdso clock mode storage") Reported-by:
-
Hill Ma authored
commit 140fd4ac upstream. On MacBook6,1 reboot would hang unless parameter reboot=pci is added. Make it automatic. Signed-off-by:
-
Anthony Steinhauser authored
commit 4d8df8cb upstream. Currently, it is possible to enable indirect branch speculation even after it was force-disabled using the PR_SPEC_FORCE_DISABLE option. Moreover, the PR_GET_SPECULATION_CTRL command gives afterwards an incorrect result (force-disabled when it is in fact enabled). This also is inconsistent vs. STIBP and the documention which cleary states that PR_SPEC_FORCE_DISABLE cannot be undone. Fix this by actually enforcing force-disabled indirect branch speculation. PR_SPEC_ENABLE called after PR_SPEC_FORCE_DISABLE now fails with -EPERM as described in the documentation. Fixes: 9137bb27 ("x86/speculation: Add prctl() control for indirect branch speculation") Signed-off-by:
-
Anthony Steinhauser authored
commit 21998a35 upstream. When STIBP is unavailable or enhanced IBRS is available, Linux force-disables the IBPB mitigation of Spectre-BTB even when simultaneous multithreading is disabled. While attempts to enable IBPB using prctl(PR_SET_SPECULATION_CTRL, PR_SPEC_INDIRECT_BRANCH, ...) fail with EPERM, the seccomp syscall (or its prctl(PR_SET_SECCOMP, ...) equivalent) which are used e.g. by Chromium or OpenSSH succeed with no errors but the application remains silently vulnerable to cross-process Spectre v2 attacks (classical BTB poisoning). At the same time the SYSFS reporting (/sys/devices/system/cpu/vulnerabilities/spectre_v2) displays that IBPB is conditionally enabled when in fact it is unconditionally disabled. STIBP is useful only when SMT is enabled. When SMT is disabled and STIBP is unavailable, it makes no sense to force-disable also IBPB, because IBPB protects against cross-process Spectre-BTB attacks regardless of the SMT state. At the same time since missing STIBP was only observed on AMD CPUs, AMD does not recommend using STIBP, but recommends using IBPB, so disabling IBPB because of missing STIBP goes directly against AMD's advice: https://developer.amd.com/wp-content/resources/Architecture_Guidelines_Update_Indirect_Branch_Control.pdf Similarly, enhanced IBRS is designed to protect cross-core BTB poisoning and BTB-poisoning attacks from user space against kernel (and BTB-poisoning attacks from guest against hypervisor), it is not designed to prevent cross-process (or cross-VM) BTB poisoning between processes (or VMs) running on the same core. Therefore, even with enhanced IBRS it is necessary to flush the BTB during context-switches, so there is no reason to force disable IBPB when enhanced IBRS is available. Enable the prctl control of IBPB even when STIBP is unavailable or enhanced IBRS is available. Fixes: 7cc765a6 ("x86/speculation: Enable prctl mode for spectre_v2_user") Signed-off-by:
-