forked from torvalds/linux
-
Notifications
You must be signed in to change notification settings - Fork 8
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
linux v6.11 with SVSM TPM support #8
Open
stefano-garzarella
wants to merge
10,000
commits into
coconut-svsm:master
Choose a base branch
from
stefano-garzarella:svsm-v6.11-vtpm
base: master
Could not load branches
Branch not found: {{ refName }}
Loading
Could not load tags
Nothing to show
Loading
Are you sure you want to change the base?
Some commits from the old base branch may be removed from the timeline,
and old review comments may become outdated.
Open
linux v6.11 with SVSM TPM support #8
stefano-garzarella
wants to merge
10,000
commits into
coconut-svsm:master
from
stefano-garzarella:svsm-v6.11-vtpm
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Fixes this missed case: xe 0000:00:02.0: [drm] Missing outer runtime PM protection WARNING: CPU: 99 PID: 1455 at drivers/gpu/drm/xe/xe_pm.c:564 xe_pm_runtime_get_noresume+0x48/0x60 [xe] Call Trace: <TASK> ? show_regs+0x67/0x70 ? __warn+0x94/0x1b0 ? xe_pm_runtime_get_noresume+0x48/0x60 [xe] ? report_bug+0x1b7/0x1d0 ? handle_bug+0x46/0x80 ? exc_invalid_op+0x19/0x70 ? asm_exc_invalid_op+0x1b/0x20 ? xe_pm_runtime_get_noresume+0x48/0x60 [xe] xe_device_declare_wedged+0x91/0x280 [xe] gt_reset_worker+0xa2/0x250 [xe] v2: Also move get and get the right Fixes tag (Himal, Brost) Fixes: fb74b20 ("drm/xe: Introduce a simple wedged state") Cc: Himal Prasad Ghimiray <[email protected]> Cc: Matthew Brost <[email protected]> Reviewed-by: Jonathan Cavitt <[email protected]> Reviewed-by: Himal Prasad Ghimiray <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Signed-off-by: Rodrigo Vivi <[email protected]> (cherry picked from commit bc947d9) Signed-off-by: Rodrigo Vivi <[email protected]>
…t/rmk/linux Pull ARM fix from Russell King: - Fix a build issue with older binutils with LD dead code elimination disabled * tag 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/rmk/linux: ARM: 9414/1: Fix build issue with LD_DEAD_CODE_DATA_ELIMINATION
Ole reported that event->mmap_mutex is strictly insufficient to serialize the AUX buffer, add a per RB mutex to fully serialize it. Note that in the lock order comment the perf_event::mmap_mutex order was already wrong, that is, it nesting under mmap_lock is not new with this patch. Fixes: 45bfb2e ("perf: Add AUX area to ring buffer for raw data streams") Reported-by: Ole <[email protected]> Signed-off-by: Peter Zijlstra (Intel) <[email protected]> Signed-off-by: Ingo Molnar <[email protected]>
Suspend fbdev sooner, and disable user access before suspending to prevent some races. I've noticed this when comparing xe suspend to i915's. Matches the following commits from i915: 24b412b ("drm/i915: Disable intel HPD poll after DRM poll init/enable") 1ef28d8 ("drm/i915: Suspend the framebuffer console earlier during system suspend") bd738d8 ("drm/i915: Prevent modesets during driver init/shutdown") Thanks to Imre for pointing me to those commits. Driver shutdown is currently missing, but I have some idea how to implement it next. Signed-off-by: Maarten Lankhorst <[email protected]> Cc: Imre Deak <[email protected]> Reviewed-by: Uma Shankar <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Signed-off-by: Maarten Lankhorst,,, <[email protected]> (cherry picked from commit 492be2a) Signed-off-by: Rodrigo Vivi <[email protected]>
Enable/Disable user access only during system suspend/resume. This should not happen during runtime s/r v2: rebased Reviewed-by: Arun R Murthy <[email protected]> Signed-off-by: Imre Deak <[email protected]> Signed-off-by: Vinod Govindapillai <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] (cherry picked from commit a64e7e5) Signed-off-by: Rodrigo Vivi <[email protected]>
Fix circular locking dependency on runtime suspend. <4> [74.952215] ====================================================== <4> [74.952217] WARNING: possible circular locking dependency detected <4> [74.952219] 6.10.0-rc7-xe #1 Not tainted <4> [74.952221] ------------------------------------------------------ <4> [74.952223] kworker/7:1/82 is trying to acquire lock: <4> [74.952226] ffff888120548488 (&dev->mode_config.mutex){+.+.}-{3:3}, at: drm_modeset_lock_all+0x40/0x1e0 [drm] <4> [74.952260] but task is already holding lock: <4> [74.952262] ffffffffa0ae59c0 (xe_pm_runtime_lockdep_map){+.+.}-{0:0}, at: xe_pm_runtime_suspend+0x2f/0x340 [xe] <4> [74.952322] which lock already depends on the new lock. The commit 'b1d90a86 ("drm/xe: Use the encoder suspend helper also used by the i915 driver")' didn't do anything wrong. It actually fixed a critical bug, because the encoder_suspend was never getting actually called because it was returning if (has_display(xe)) instead of if (!has_display(xe)). However, this ended up introducing the encoder suspend calls in the runtime routines as well, causing the circular locking dependency. Closes: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/2304 Fixes: b1d90a8 ("drm/xe: Use the encoder suspend helper also used by the i915 driver") Cc: Imre Deak <[email protected]> Reviewed-by: Jonathan Cavitt <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Signed-off-by: Rodrigo Vivi <[email protected]> (cherry picked from commit 8da1944) Signed-off-by: Rodrigo Vivi <[email protected]>
…kernel/git/vfs/vfs Pull vfs fixes from Christian Brauner: "Two netfs fixes for this merge window: - Ensure that fscache_cookie_lru_time is deleted when the fscache module is removed to prevent UAF - Fix filemap_invalidate_inode() to use invalidate_inode_pages2_range() Before it used truncate_inode_pages_partial() which causes copy_file_range() to fail on cifs" * tag 'vfs-6.11-rc7.fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/vfs/vfs: fscache: delete fscache_cookie_lru_timer when fscache exits to avoid UAF mm: Fix filemap_invalidate_inode() to use invalidate_inode_pages2_range()
Pull smb server fixes from Steve French: - Fix crash in session setup - Fix locking bug - Improve access bounds checking * tag 'v6.11-rc6-server-fixes' of git://git.samba.org/ksmbd: ksmbd: Unlock on in ksmbd_tcp_set_interfaces() ksmbd: unset the binding mark of a reused connection smb: Annotate struct xattr_smb_acl with __counted_by()
…rnel/git/kdave/linux Pull btrfs fixes from David Sterba: - followup fix for direct io and fsync under some conditions, reported by QEMU users - fix a potential leak when disabling quotas while some extent tracking work can still happen - in zoned mode handle unexpected change of zone write pointer in RAID1-like block groups, turn the zones to read-only * tag 'for-6.11-rc6-tag' of git://git.kernel.org/pub/scm/linux/kernel/git/kdave/linux: btrfs: fix race between direct IO write and fsync when using same fd btrfs: zoned: handle broken write pointer on zones btrfs: qgroup: don't use extent changeset when not needed
If the length of the name string is 1 and the value of name[0] is NULL byte, an OOB vulnerability occurs in btf_name_valid_section() and the return value is true, so the invalid name passes the check. To solve this, you need to check if the first position is NULL byte and if the first character is printable. Suggested-by: Eduard Zingerman <[email protected]> Fixes: bd70a8f ("bpf: Allow all printable characters in BTF DATASEC names") Signed-off-by: Jeongjun Park <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Alexei Starovoitov <[email protected]> Acked-by: Eduard Zingerman <[email protected]>
…/kernel/git/groeck/linux-staging Pull hwmon fixes from Guenter Roeck: - hp-wmi-sensors: Check if WMI event data exists before accessing it - ltc2991: fix register bits defines * tag 'hwmon-for-v6.11-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/groeck/linux-staging: hwmon: (hp-wmi-sensors) Check if WMI event data exists hwmon: ltc2991: fix register bits defines
….org/pub/scm/linux/kernel/git/perf/perf-tools Pull perf tools fixes from Namhyung Kim: "A number of small fixes for the late cycle: - Two more build fixes on 32-bit archs - Fixed a segfault during perf test - Fixed spinlock/rwlock accounting bug in perf lock contention" * tag 'perf-tools-fixes-for-v6.11-2024-09-04' of git://git.kernel.org/pub/scm/linux/kernel/git/perf/perf-tools: perf daemon: Fix the build on more 32-bit architectures perf python: include "util/sample.h" perf lock contention: Fix spinlock and rwlock accounting perf test pmu: Set uninitialized PMU alias to null
Add selftest for cases where btf_name_valid_section() does not properly check for certain types of names. Suggested-by: Eduard Zingerman <[email protected]> Signed-off-by: Jeongjun Park <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Alexei Starovoitov <[email protected]> Acked-by: Eduard Zingerman <[email protected]>
…id_section' Jeongjun Park says: ==================== bpf: fix incorrect name check pass logic in btf_name_valid_section This patch was written to fix an issue where btf_name_valid_section() would not properly check names with certain conditions and would throw an OOB vuln. And selftest was added to verify this patch. ==================== Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Alexei Starovoitov <[email protected]>
Pull bcachefs fixes from Kent Overstreet: - Fix a typo in the rebalance accounting changes - BCH_SB_MEMBER_INVALID: small on disk format feature which will be needed for full erasure coding support; this is only the minimum so that 6.11 can handle future versions without barfing. * tag 'bcachefs-2024-09-04' of git://evilpiepirate.org/bcachefs: bcachefs: BCH_SB_MEMBER_INVALID bcachefs: fix rebalance accounting
Bareudp devices update their stats concurrently. Therefore they need proper atomic increments. Fixes: 571912c ("net: UDP tunnel encapsulation module for tunnelling different protocols like MPLS, IP, NSH etc.") Signed-off-by: Guillaume Nault <[email protected]> Reviewed-by: Willem de Bruijn <[email protected]> Link: https://patch.msgid.link/04b7b9d0b480158eb3ab4366ec80aa2ab7e41fcb.1725031794.git.gnault@redhat.com Signed-off-by: Jakub Kicinski <[email protected]>
We observed a null-ptr-deref in fou_gro_receive() while shutting down a host. [0] The NULL pointer is sk->sk_user_data, and the offset 8 is of protocol in struct fou. When fou_release() is called due to netns dismantle or explicit tunnel teardown, udp_tunnel_sock_release() sets NULL to sk->sk_user_data. Then, the tunnel socket is destroyed after a single RCU grace period. So, in-flight udp4_gro_receive() could find the socket and execute the FOU GRO handler, where sk->sk_user_data could be NULL. Let's use rcu_dereference_sk_user_data() in fou_from_sock() and add NULL checks in FOU GRO handlers. [0]: BUG: kernel NULL pointer dereference, address: 0000000000000008 PF: supervisor read access in kernel mode PF: error_code(0x0000) - not-present page PGD 80000001032f4067 P4D 80000001032f4067 PUD 103240067 PMD 0 SMP PTI CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.10.216-204.855.amzn2.x86_64 #1 Hardware name: Amazon EC2 c5.large/, BIOS 1.0 10/16/2017 RIP: 0010:fou_gro_receive (net/ipv4/fou.c:233) [fou] Code: 41 5f c3 cc cc cc cc e8 e7 2e 69 f4 0f 1f 80 00 00 00 00 0f 1f 44 00 00 49 89 f8 41 54 48 89 f7 48 89 d6 49 8b 80 88 02 00 00 <0f> b6 48 08 0f b7 42 4a 66 25 fd fd 80 cc 02 66 89 42 4a 0f b6 42 RSP: 0018:ffffa330c0003d08 EFLAGS: 00010297 RAX: 0000000000000000 RBX: ffff93d9e3a6b900 RCX: 0000000000000010 RDX: ffff93d9e3a6b900 RSI: ffff93d9e3a6b900 RDI: ffff93dac2e24d08 RBP: ffff93d9e3a6b900 R08: ffff93dacbce6400 R09: 0000000000000002 R10: 0000000000000000 R11: ffffffffb5f369b0 R12: ffff93dacbce6400 R13: ffff93dac2e24d08 R14: 0000000000000000 R15: ffffffffb4edd1c0 FS: 0000000000000000(0000) GS:ffff93daee800000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000008 CR3: 0000000102140001 CR4: 00000000007706f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: <IRQ> ? show_trace_log_lvl (arch/x86/kernel/dumpstack.c:259) ? __die_body.cold (arch/x86/kernel/dumpstack.c:478 arch/x86/kernel/dumpstack.c:420) ? no_context (arch/x86/mm/fault.c:752) ? exc_page_fault (arch/x86/include/asm/irqflags.h:49 arch/x86/include/asm/irqflags.h:89 arch/x86/mm/fault.c:1435 arch/x86/mm/fault.c:1483) ? asm_exc_page_fault (arch/x86/include/asm/idtentry.h:571) ? fou_gro_receive (net/ipv4/fou.c:233) [fou] udp_gro_receive (include/linux/netdevice.h:2552 net/ipv4/udp_offload.c:559) udp4_gro_receive (net/ipv4/udp_offload.c:604) inet_gro_receive (net/ipv4/af_inet.c:1549 (discriminator 7)) dev_gro_receive (net/core/dev.c:6035 (discriminator 4)) napi_gro_receive (net/core/dev.c:6170) ena_clean_rx_irq (drivers/amazon/net/ena/ena_netdev.c:1558) [ena] ena_io_poll (drivers/amazon/net/ena/ena_netdev.c:1742) [ena] napi_poll (net/core/dev.c:6847) net_rx_action (net/core/dev.c:6917) __do_softirq (arch/x86/include/asm/jump_label.h:25 include/linux/jump_label.h:200 include/trace/events/irq.h:142 kernel/softirq.c:299) asm_call_irq_on_stack (arch/x86/entry/entry_64.S:809) </IRQ> do_softirq_own_stack (arch/x86/include/asm/irq_stack.h:27 arch/x86/include/asm/irq_stack.h:77 arch/x86/kernel/irq_64.c:77) irq_exit_rcu (kernel/softirq.c:393 kernel/softirq.c:423 kernel/softirq.c:435) common_interrupt (arch/x86/kernel/irq.c:239) asm_common_interrupt (arch/x86/include/asm/idtentry.h:626) RIP: 0010:acpi_idle_do_entry (arch/x86/include/asm/irqflags.h:49 arch/x86/include/asm/irqflags.h:89 drivers/acpi/processor_idle.c:114 drivers/acpi/processor_idle.c:575) Code: 8b 15 d1 3c c4 02 ed c3 cc cc cc cc 65 48 8b 04 25 40 ef 01 00 48 8b 00 a8 08 75 eb 0f 1f 44 00 00 0f 00 2d d5 09 55 00 fb f4 <fa> c3 cc cc cc cc e9 be fc ff ff 66 66 2e 0f 1f 84 00 00 00 00 00 RSP: 0018:ffffffffb5603e58 EFLAGS: 00000246 RAX: 0000000000004000 RBX: ffff93dac0929c00 RCX: ffff93daee833900 RDX: ffff93daee800000 RSI: ffff93daee87dc00 RDI: ffff93daee87dc64 RBP: 0000000000000001 R08: ffffffffb5e7b6c0 R09: 0000000000000044 R10: ffff93daee831b04 R11: 00000000000001cd R12: 0000000000000001 R13: ffffffffb5e7b740 R14: 0000000000000001 R15: 0000000000000000 ? sched_clock_cpu (kernel/sched/clock.c:371) acpi_idle_enter (drivers/acpi/processor_idle.c:712 (discriminator 3)) cpuidle_enter_state (drivers/cpuidle/cpuidle.c:237) cpuidle_enter (drivers/cpuidle/cpuidle.c:353) cpuidle_idle_call (kernel/sched/idle.c:158 kernel/sched/idle.c:239) do_idle (kernel/sched/idle.c:302) cpu_startup_entry (kernel/sched/idle.c:395 (discriminator 1)) start_kernel (init/main.c:1048) secondary_startup_64_no_verify (arch/x86/kernel/head_64.S:310) Modules linked in: udp_diag tcp_diag inet_diag nft_nat ipip tunnel4 dummy fou ip_tunnel nft_masq nft_chain_nat nf_nat wireguard nft_ct curve25519_x86_64 libcurve25519_generic nf_conntrack libchacha20poly1305 nf_defrag_ipv6 nf_defrag_ipv4 nft_objref chacha_x86_64 nft_counter nf_tables nfnetlink poly1305_x86_64 ip6_udp_tunnel udp_tunnel libchacha crc32_pclmul ghash_clmulni_intel aesni_intel crypto_simd cryptd glue_helper mousedev psmouse button ena ptp pps_core crc32c_intel CR2: 0000000000000008 Fixes: d92283e ("fou: change to use UDP socket GRO") Reported-by: Alphonse Kurian <[email protected]> Signed-off-by: Kuniyuki Iwashima <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]>
generic_ocp_write() asks the parameter "size" must be 4 bytes align. Therefore, write the bp would fail, if the mac->bp_num is odd. Align the size to 4 for fixing it. The way may write an extra bp, but the rtl8152_is_fw_mac_ok() makes sure the value must be 0 for the bp whose index is more than mac->bp_num. That is, there is no influence for the firmware. Besides, I check the return value of generic_ocp_write() to make sure everything is correct. Fixes: e5c266a ("r8152: set bp in bulk") Signed-off-by: Hayes Wang <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]>
When userspace wants to take over a fdb entry by setting it as EXTERN_LEARNED, we set both flags BR_FDB_ADDED_BY_EXT_LEARN and BR_FDB_ADDED_BY_USER in br_fdb_external_learn_add(). If the bridge updates the entry later because its port changed, we clear the BR_FDB_ADDED_BY_EXT_LEARN flag, but leave the BR_FDB_ADDED_BY_USER flag set. If userspace then wants to take over the entry again, br_fdb_external_learn_add() sees that BR_FDB_ADDED_BY_USER and skips setting the BR_FDB_ADDED_BY_EXT_LEARN flags, thus silently ignores the update. Fix this by always allowing to set BR_FDB_ADDED_BY_EXT_LEARN regardless if this was a user fdb entry or not. Fixes: 710ae72 ("net: bridge: Mark FDB entries that were added by user as such") Signed-off-by: Jonas Gorski <[email protected]> Acked-by: Nikolay Aleksandrov <[email protected]> Reviewed-by: Ido Schimmel <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]>
axienet_dma_err_handler can race with axienet_stop in the following manner: CPU 1 CPU 2 ====================== ================== axienet_stop() napi_disable() axienet_dma_stop() axienet_dma_err_handler() napi_disable() axienet_dma_stop() axienet_dma_start() napi_enable() cancel_work_sync() free_irq() Fix this by setting a flag in axienet_stop telling axienet_dma_err_handler not to bother doing anything. I chose not to use disable_work_sync to allow for easier backporting. Signed-off-by: Sean Anderson <[email protected]> Fixes: 8a3b7a2 ("drivers/net/ethernet/xilinx: added Xilinx AXI Ethernet driver") Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]>
…/kernel/git/wireless/wireless Kalle Valo says: ==================== wireless fixes for v6.11 Hopefully final fixes for v6.11 and this time only fixes to ath11k driver. We need to revert hibernation support due to reported regressions and we have a fix for kernel crash introduced in v6.11-rc1. * tag 'wireless-2024-09-04' of git://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless: MAINTAINERS: wifi: cw1200: add net-cw1200.h Revert "wifi: ath11k: support hibernation" Revert "wifi: ath11k: restore country code during resume" wifi: ath11k: fix NULL pointer dereference in ath11k_mac_get_eirp_power() ==================== Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]>
…t/tnguy/net-queue Tony Nguyen says: ==================== ice: fix synchronization between .ndo_bpf() and reset Larysa Zaremba says: PF reset can be triggered asynchronously, by tx_timeout or by a user. With some unfortunate timings both ice_vsi_rebuild() and .ndo_bpf will try to access and modify XDP rings at the same time, causing system crash. The first patch factors out rtnl-locked code from VSI rebuild code to avoid deadlock. The following changes lock rebuild and .ndo_bpf() critical sections with an internal mutex as well and provide complementary fixes. * '100GbE' of git://git.kernel.org/pub/scm/linux/kernel/git/tnguy/net-queue: ice: do not bring the VSI up, if it was down before the XDP setup ice: remove ICE_CFG_BUSY locking from AF_XDP code ice: check ICE_VSI_DOWN under rtnl_lock when preparing for reset ice: check for XDP rings instead of bpf program when unconfiguring ice: protect XDP configuration with a mutex ice: move netif_queue_set_napi to rtnl-protected sections ==================== Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]>
commit 9636be8 ("x86/hyperv: Fix hyperv_pcpu_input_arg handling when CPUs go online/offline") introduces a new cpuhp state for hyperv initialization. cpuhp_setup_state() returns the state number if state is CPUHP_AP_ONLINE_DYN or CPUHP_BP_PREPARE_DYN and 0 for all other states. For the hyperv case, since a new cpuhp state was introduced it would return 0. However, in hv_machine_shutdown(), the cpuhp_remove_state() call is conditioned upon "hyperv_init_cpuhp > 0". This will never be true and so hv_cpu_die() won't be called on all CPUs. This means the VP assist page won't be reset. When the kexec kernel tries to setup the VP assist page again, the hypervisor corrupts the memory region of the old VP assist page causing a panic in case the kexec kernel is using that memory elsewhere. This was originally fixed in commit dfe94d4 ("x86/hyperv: Fix kexec panic/hang issues"). Get rid of hyperv_init_cpuhp entirely since we are no longer using a dynamic cpuhp state and use CPUHP_AP_HYPERV_ONLINE directly with cpuhp_remove_state(). Cc: [email protected] Fixes: 9636be8 ("x86/hyperv: Fix hyperv_pcpu_input_arg handling when CPUs go online/offline") Signed-off-by: Anirudh Rayabharam (Microsoft) <[email protected]> Reviewed-by: Vitaly Kuznetsov <[email protected]> Reviewed-by: Michael Kelley <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Wei Liu <[email protected]> Message-ID: <[email protected]>
rm .*.cmd when make clean Signed-off-by: zhang jiao <[email protected]> Reviewed-by: Saurabh Sengar <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Wei Liu <[email protected]> Message-ID: <[email protected]>
We were allowing any users to create a high priority group without any permission checks. As a result, this was allowing possible denial of service. We now only allow the DRM master or users with the CAP_SYS_NICE capability to set higher priorities than PANTHOR_GROUP_PRIORITY_MEDIUM. As the sole user of that uAPI lives in Mesa and hardcode a value of MEDIUM [1], this should be safe to do. Additionally, as those checks are performed at the ioctl level, panthor_group_create now only check for priority level validity. [1]https://gitlab.freedesktop.org/mesa/mesa/-/blob/f390835074bdf162a63deb0311d1a6de527f9f89/src/gallium/drivers/panfrost/pan_csf.c#L1038 Signed-off-by: Mary Guillemard <[email protected]> Fixes: de85488 ("drm/panthor: Add the scheduler logical block") Cc: [email protected] Reviewed-by: Boris Brezillon <[email protected]> Signed-off-by: Boris Brezillon <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
The WL-355608-A8 is a 3.5" 640x480@60Hz RGB LCD display from an unknown OEM used in a number of handheld gaming devices made by Anbernic. Previously committed using the OEM serial without a vendor prefix, however following subsequent discussion the preference is to use the integrating device vendor and name where the OEM is unknown. There are 4 RG35XX series devices from Anbernic based on an Allwinner H700 SoC using this panel, with the -Plus variant introduced first. Therefore the -Plus is used as the fallback for the subsequent -H, -2024, and -SP devices. Alter the filename and compatible string to reflect the convention. Fixes: 45b888a ("dt-bindings: display: panel: Add WL-355608-A8 panel") Signed-off-by: Ryan Walklin <[email protected]> Acked-by: Rob Herring (Arm) <[email protected]> Signed-off-by: Maxime Ripard <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
As per the previous dt-binding commit, update the WL-355608-A8 panel compatible to reflect the the integrating device vendor and name as the panel OEM is unknown. Fixes: 62ea2ee ("drm: panel: nv3052c: Add WL-355608-A8 panel") Signed-off-by: Ryan Walklin <[email protected]> Signed-off-by: Maxime Ripard <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
In the off-chance that waiting for the firmware to signal its booted status timed out in the fast reset path, one must flush the cache lines for the entire FW VM address space before reloading the regions, otherwise stale values eventually lead to a scheduler job timeout. Fixes: 647810e ("drm/panthor: Add the MMU/VM logical block") Cc: [email protected] Signed-off-by: Adrián Larumbe <[email protected]> Acked-by: Liviu Dudau <[email protected]> Reviewed-by: Steven Price <[email protected]> Reviewed-by: Boris Brezillon <[email protected]> Signed-off-by: Boris Brezillon <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
Document what was discussed multiple times on list and various virtual / in-person conversations. guard() being okay in functions <= 20 LoC is a bit of my own invention. If the function is trivial it should be fine, but feel free to disagree :) We'll obviously revisit this guidance as time passes and we and other subsystems get more experience. Reviewed-by: Eric Dumazet <[email protected]> Reviewed-by: Nikolay Aleksandrov <[email protected]> Reviewed-by: Andrew Lunn <[email protected]> Signed-off-by: Jakub Kicinski <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Paolo Abeni <[email protected]>
Deferred I/O requires struct page for framebuffer memory, which is not guaranteed for all DMA ranges. We thus only install deferred I/O if we have a framebuffer that requires it. A reported bug affected the ipu-v3 and pl111 drivers, which have video memory in either Normal or HighMem zones [ 0.000000] Zone ranges: [ 0.000000] Normal [mem 0x0000000010000000-0x000000003fffffff] [ 0.000000] HighMem [mem 0x0000000040000000-0x000000004fffffff] where deferred I/O only works correctly with HighMem. See the Closes tags for bug reports. v2: - test if screen_buffer supports deferred I/O (Sima) Signed-off-by: Thomas Zimmermann <[email protected]> Fixes: 808a40b ("drm/fbdev-dma: Implement damage handling and deferred I/O") Reported-by: Alexander Stein <[email protected]> Closes: https://lore.kernel.org/all/23636953.6Emhk5qWAg@steina-w/ Reported-by: Linus Walleij <[email protected]> Closes: https://lore.kernel.org/dri-devel/CACRpkdb+hb9AGavbWpY-=uQQ0apY9en_tWJioPKf_fAbXMP4Hg@mail.gmail.com/ Tested-by: Alexander Stein <[email protected]> Tested-by: Linus Walleij <[email protected]> Cc: Thomas Zimmermann <[email protected]> Cc: Javier Martinez Canillas <[email protected]> Cc: Maarten Lankhorst <[email protected]> Cc: Maxime Ripard <[email protected]> Reviewed-by: Simona Vetter <[email protected]> Reviewed-by: Linus Walleij <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
…it/tiwai/sound Pull sound fixes from Takashi Iwai: "A few last-minute ASoC fixes and MAINTAINERS update. All look small, obvious and nice-to-have fixes for 6.11-final" * tag 'sound-6.11' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound: ASoC: meson: axg-card: fix 'use-after-free' ASoC: codecs: avoid possible garbage value in peb2466_reg_read() MAINTAINERS: update Pierre Bossart's email and role ASoC: tas2781: fix to save the dsp bin file name into the correct array in case name_prefix is not NULL ASoC: Intel: soc-acpi-intel-mtl-match: add missing empty item ASoC: Intel: soc-acpi-intel-lnl-match: add missing empty item
…nel/git/linusw/linux-pinctrl Pull pin control fixes from Linus Walleij: - One Intel patch that I mistakenly merged into for-next despite it belonging in fixes: add Arrow Lake-H/U ACPI ID so this Arrow Lake chip probes. - One fix making the CY895x0 reg cache work, which is good because it makes the device work too. * tag 'pinctrl-v6.11-4' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl: pinctrl: pinctrl-cy8c95x0: Fix regcache pinctrl: meteorlake: Add Arrow Lake-H/U ACPI ID
…oop" This reverts commit 377b2f3. This caused a regression with the bochsdrm driver, which used ioremap() instead of ioremap_wc() to map the video RAM. After the commit, the WB memory type is used without the IGNORE_PAT, resulting in the slower UC memory type. In fact, UC is slow enough to basically cause guests to not boot... but only on new processors such as Sapphire Rapids and Cascade Lake. Coffee Lake for example works properly, though that might also be an effect of being on a larger, more NUMA system. The driver has been fixed but that does not help older guests. Until we figure out whether Cascade Lake and newer processors are working as intended, revert the commit. Long term we might add a quirk, but the details depend on whether the processors are working as intended: for example if they are, the quirk might reference bochs-compatible devices, e.g. in the name and documentation, so that userspace can disable the quirk by default and only leave it enabled if such a device is being exposed to the guest. If instead this is actually a bug in CLX+, then the actions we need to take are different and depend on the actual cause of the bug. Signed-off-by: Paolo Bonzini <[email protected]>
Pull kvm fix from Paolo Bonzini: "Do not always honor guest PAT on CPUs that support self-snoop. This triggers an issue in the bochsdrm driver, which used ioremap() instead of ioremap_wc() to map the video RAM. The revert lets video RAM use the WB memory type instead of the slower UC memory type" * tag 'for-linus-6.11' of git://git.kernel.org/pub/scm/virt/kvm/kvm: Revert "KVM: VMX: Always honor guest PAT on CPUs that support self-snoop"
Implement the GET_APIC_IDS NAE event to gather and return the list of APIC IDs for all vCPUs in the guest. Signed-off-by: Tom Lendacky <[email protected]>
Update AP creation to support ADD/DESTROY of VMSAs at levels other than VMPL0 in order to run under an SVSM at VMPL1 or lower. To maintain backwards compatibility, the VMPL is specified in bits 16 to 19 of the AP Creation request in SW_EXITINFO1 of the GHCB. In order to track the VMSAs at different levels, create arrays for the VMSAs, GHCBs, registered GHCBs and others. When switching VMPL levels, these entries will be used to set the VMSA and GHCB physical addresses in the VMCB for the VMPL level. In order ensure that the proper responses are returned in the proper GHCB, the GHCB must be unmapped at the current level and saved for restoration later when switching back to that VMPL level. Additional checks are applied to prevent a non-VMPL0 vCPU from being able to perform an AP creation request at VMPL0. Additionally, a vCPU cannot replace its own VMSA. Signed-off-by: Tom Lendacky <[email protected]>
Implement the SNP Run VMPL NAE event and MSR protocol to allow a guest to request a different VMPL level VMSA be run for the vCPU. This allows the guest to "call" an SVSM to process an SVSM request. Signed-off-by: Tom Lendacky <[email protected]>
Make struct kvm_sev_info maintain separate SEV features per VMPL, allowing distinct SEV features depending on VMs privilege level. Signed-off-by: Carlos Bilbao <[email protected]> Signed-off-by: Tom Lendacky <[email protected]>
Prevent injection of exceptions/interrupts when restricted injection is active. This is not full support for restricted injection, but the SVSM is not expecting any injections at all. Signed-off-by: Tom Lendacky <[email protected]>
Allow Restricted Injection to be set in SEV_FEATURES. When set, attempts to inject any interrupts other than #HV will make VMRUN fail. This is done to further reduce the security exposure within the SVSM. Signed-off-by: Tom Lendacky <[email protected]>
Allow for setting VMPL permission as part of the launch sequence and ssing an SNP init flag, limit measuring of the guest vCPUs, to just the BSP. Indicate full multi-VMPL support to the guest through the GHCB feature bitmap. Signed-off-by: Tom Lendacky <[email protected]>
This commit is in preparation for supporting multiple VM privilege levels (VMPLs) within KVM by creating an instance of struct kvm_vcpu for each VMPL. Support for multiple VMPLs will be introduced in a later commit. This commit prepares struct kvm_vcpu by allowing the fields that are common to all VMPLs to be accessed from the struct kvm_vcpu for any VMPL. To add support for common fields across multiple struct kvm_vcpus, this commit creates a sub-structure within struct kvm_vcpu for storing the common fields. Any fields that have been identified as common across VMPLs for SEV-SNP (for now) have been moved into this sub-structure. When the struct kvm_vcpu is initialised, a pointer to the common structure is stored within struct kvm_vcpu allowing access to the common fields. This means that any reference to these common fields needs to be updated to access them via the structure pointer, e.g. vcpu->common->[common_field]. This has resulted in this patch generating many small changes to many files which is an unfortunate side-effect of this implementation. Signed-off-by: Roy Hopkins <[email protected]>
Isolation technologies such as SEV-SNP introduce the concept of virtual machine privilege levels (VMPLs), separate to the processor CPL. A guest runs in the context of one of these VMPLs which allows for a different register context, memory privileges, etc. KVM must maintain state for each supported VMPL and switch between these states before entering the guest based on guest requests or other factors. This patch introduces the ability to create multiple struct kvm_cpus: one for each VMPL related to a single vCPU. This is achieved by introducing a new structure, struct kvm_vcpu_vmpl_state that is included in struct kvm_vcpu to track the state of each VMPL for supported platforms (currently only SEV-SNP). The state for each VMPL is then stored in its own struct kvm_vcpu. State that is common to all VMPL kvm_vcpus is managed by vcpu->common, allowing a pointer to the common fields to be shared amongst all VMPL kvm_vcpu's for a single vCPU id. The patch supports switching VMPLs by changing the target_vmpl in the state structure. However, no code to generate a VMPL switch invokes this at present. Signed-off-by: Roy Hopkins <[email protected]>
This commit builds on Tom Lendacky's SEV-SNP support RFC patch series and reworks the handling of VMPL switching to use multiple struct kvm_vcpus to store VMPL context. Signed-off-by: Roy Hopkins <[email protected]>
When a CPU supports multiple VMPLs, injected interrupts need to be sent to the correct context. This commit adds an operation that determines the VMPL number that IRQs should be sent to in the absence of an explicit target VMPL. Signed-off-by: Roy Hopkins <[email protected]>
Systems that support VMPLs need to decide which VMPL each IRQ is destined for; each VMPL can support its own set of hardware devices that generate interrupts. This commit extends kvm_lapic_irq to include a target_vmpl field the sends the IRQ to the APIC instance at the target VMPL. Signed-off-by: Roy Hopkins <[email protected]>
… VMPL The struct kvm_vcpu for each VMPL manages its own requests. Currently, kvm_make_all_cpus_request() and kvm_make_vcpus_request_mask() allow requests to be sent for VMPL0. This patch introduces two new functions: kvm_make_all_cpus_request_vmpl() and kvm_make_vcpus_request_mask_vmpl() that allow a particular VMPL to be targeted. Signed-off-by: Roy Hopkins <[email protected]>
Currently all IRQ requests are targeted to the lowest priority VMPL which is where the OS will be running. This patch updates the IOAPIC request scan to use the default IRQ VMPL from the KVM arch configuration. Signed-off-by: Roy Hopkins <[email protected]>
The VMSA containing the initial CPU state for an SEV-SNP guest is measured as part of the launch process. Currently, KVM does this automatically during the call to KVM_SEV_SNP_LAUNCH_FINISH where the CPU state is synchronised to the VMSA for every vCPU, measured then the guest is launched. This poses a problem for guests that want to have full control over the number and contents of VMSAs, such as when using an SVSM module or paravisor. In which case, for example, you may only want the BSP VMSA to be provided, or have full control over non-synced registers. As soon as the VMSA is measured it is encrypted by hardware so KVM immediately loses sight and control over the contents. With this in mind, there is no need to keep the VMSA in sync with KVMs view of register state. Therefore it makes sense to bypass the sync completely and provide a way for the VMSA to be directly specified from userspace if required. This commit extends the KVM_SEV_SNP_LAUNCH_UPDATE ioctl to allow VMSA pages to be updated. When encountered, this modifies the behaviour of KVM_SEV_SNP_LAUNCH_FINISH to prevent the sync and measurement of CPU state. This allows for both legacy functionaly and new functionality to co-exist. Signed-off-by: Roy Hopkins <[email protected]>
Restricted injection is a feature which enforces additional interrupt and event injection security protections for a SEV-SNP guest. It disables all hypervisor-based interrupt queuing and event injection of all vectors except a new exception vector, #HV (28), which is reserved for SNP guest use, but never generated by hardware. #HV is only allowed to be injected into VMSAs that execute with Restricted Injection. The guests running with the SNP restricted injection feature active limit the host to ringing a doorbell with a #HV exception. Define two fields in the #HV doorbell page: a pending event field, and an EOI assist. Create the structure definition for the #HV doorbell page as per GHCB specification. Co-developed-by: Thomas Lendacky <[email protected]> Signed-off-by: Thomas Lendacky <[email protected]> Signed-off-by: Melody Wang <[email protected]>
To support the SEV-SNP Restricted Injection feature, the SEV-SNP guest must register a #HV doorbell page for use with the #HV. The #HV doorbell page NAE event allows the guest to register a #HV doorbell page. The NAE event consists of four actions: GET_PREFERRED, SET, QUERY, CLEAR. Implement the NAE event as per GHCB specification. Co-developed-by: Thomas Lendacky <[email protected]> Signed-off-by: Thomas Lendacky <[email protected]> Signed-off-by: Melody Wang <[email protected]>
When restricted injection is active, only #HV exceptions can be injected into the SEV-SNP guest. Detect that restricted injection feature is active for the guest, and then follow the #HV doorbell communication from the GHCB specification to inject the interrupt or exception. Co-developed-by: Thomas Lendacky <[email protected]> Signed-off-by: Thomas Lendacky <[email protected]> Signed-off-by: Melody Wang <[email protected]>
When restricted injection is active, only #HV exceptions can be injected into the SEV-SNP guest. Detect that restricted injection feature is active for the guest, and then follow the #HV doorbell communication from the GHCB specification to inject NMIs. Co-developed-by: Thomas Lendacky <[email protected]> Signed-off-by: Thomas Lendacky <[email protected]> Signed-off-by: Melody Wang <[email protected]>
When restricted injection is active, only #HV exceptions can be injected into the SEV-SNP guest. Detect that restricted injection feature is active for the guest, and then follow the #HV doorbell communication from the GHCB specification to inject the MCEs. Co-developed-by: Thomas Lendacky <[email protected]> Signed-off-by: Thomas Lendacky <[email protected]> Signed-off-by: Melody Wang <[email protected]>
Enable the restricted injection in an SEV-SNP guest by setting the restricted injection bit in the VMSA SEV features field (SEV_FEATURES[3]) from QEMU. Add the restricted injection supporting the hypervisor advertised features. Co-developed-by: Thomas Lendacky <[email protected]> Signed-off-by: Thomas Lendacky <[email protected]> Signed-off-by: Melody Wang <[email protected]>
Each vCPU VMPL maintains its own set of pending events. When a vCPU is kicked or exits back to the host, check using an X86 op to see if events are pending for a higher priority VMPL and allow switching to that VMPL. This has been implemented for SEV-SNP where VMPL0 is checked when running a lower VMPL and the current_vmpl is switched to VMPL0 if there are pending events. Signed-off-by: Roy Hopkins <[email protected]>
This is primarily designed to support an enlightened driver for the AMD svsm based vTPM, but it could be used by any platform which communicates with a TPM device. The platform must fill in struct tpm_platform_ops as the platform_data and set the device name to "tpm" to have the binding by name work correctly. The sole sendrecv function is designed to do a single buffer request/response conforming to the MSSIM protocol. For the svsm vTPM case, this protocol is transmitted directly to the SVSM, but it could be massaged for other function type platform interfaces. Signed-off-by: James Bottomley <[email protected]> Signed-off-by: Joerg Roedel <[email protected]> Signed-off-by: Stefano Garzarella <[email protected]>
If the SNP boot has a SVSM, probe for the vTPM device by sending a SVSM_VTPM_QUERY call (function 8). The SVSM will return a bitmap with the TPM_SEND_COMMAND bit set only if the vTPM is present and it is able to handle TPM commands at runtime. If a vTPM is found, register a platform device as "platform:tpm" so it can be attached to the tpm_platform.c driver. Signed-off-by: James Bottomley <[email protected]> Signed-off-by: Joerg Roedel <[email protected]> [SG] Code adjusted with some changes introduced in 6.11 Signed-off-by: Stefano Garzarella <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This is based on #7 with 2 patches on top from the svsm branch to support the SVSM TPM in the guest.
I just adapted them with some changes introduced in v6.11