Skip to content
Snippets Groups Projects
  1. Sep 30, 2024
  2. Sep 20, 2024
    • Lyude Paul's avatar
      drm/panic: Fix uninitialized spinlock acquisition with CONFIG_DRM_PANIC=n · 7be6db63
      Lyude Paul authored
      
      It turns out that if you happen to have a kernel config where
      CONFIG_DRM_PANIC is disabled and spinlock debugging is enabled, along with
      KMS being enabled - we'll end up trying to acquire an uninitialized
      spin_lock with drm_panic_lock() when we try to do a commit:
      
        rvkms rvkms.0: [drm:drm_atomic_commit] committing 0000000068d2ade1
        INFO: trying to register non-static key.
        The code is fine but needs lockdep annotation, or maybe
        you didn't initialize this object before use?
        turning off the locking correctness validator.
        CPU: 4 PID: 1347 Comm: modprobe Not tainted 6.10.0-rc1Lyude-Test+ #272
        Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS edk2-20240524-3.fc40 05/24/2024
        Call Trace:
         <TASK>
         dump_stack_lvl+0x77/0xa0
         assign_lock_key+0x114/0x120
         register_lock_class+0xa8/0x2c0
         __lock_acquire+0x7d/0x2bd0
         ? __vmap_pages_range_noflush+0x3a8/0x550
         ? drm_atomic_helper_swap_state+0x2ad/0x3a0
         lock_acquire+0xec/0x290
         ? drm_atomic_helper_swap_state+0x2ad/0x3a0
         ? lock_release+0xee/0x310
         _raw_spin_lock_irqsave+0x4e/0x70
         ? drm_atomic_helper_swap_state+0x2ad/0x3a0
         drm_atomic_helper_swap_state+0x2ad/0x3a0
         drm_atomic_helper_commit+0xb1/0x270
         drm_atomic_commit+0xaf/0xe0
         ? __pfx___drm_printfn_info+0x10/0x10
         drm_client_modeset_commit_atomic+0x1a1/0x250
         drm_client_modeset_commit_locked+0x4b/0x180
         drm_client_modeset_commit+0x27/0x50
         __drm_fb_helper_restore_fbdev_mode_unlocked+0x76/0x90
         drm_fb_helper_set_par+0x38/0x40
         fbcon_init+0x3c4/0x690
         visual_init+0xc0/0x120
         do_bind_con_driver+0x409/0x4c0
         do_take_over_console+0x233/0x280
         do_fb_registered+0x11f/0x210
         fbcon_fb_registered+0x2c/0x60
         register_framebuffer+0x248/0x2a0
         __drm_fb_helper_initial_config_and_unlock+0x58a/0x720
         drm_fbdev_generic_client_hotplug+0x6e/0xb0
         drm_client_register+0x76/0xc0
         _RNvXs_CsHeezP08sTT_5rvkmsNtB4_5RvkmsNtNtCs1cdwasc6FUb_6kernel8platform6Driver5probe+0xed2/0x1060 [rvkms]
         ? _RNvMs_NtCs1cdwasc6FUb_6kernel8platformINtB4_7AdapterNtCsHeezP08sTT_5rvkms5RvkmsE14probe_callbackBQ_+0x2b/0x70 [rvkms]
         ? acpi_dev_pm_attach+0x25/0x110
         ? platform_probe+0x6a/0xa0
         ? really_probe+0x10b/0x400
         ? __driver_probe_device+0x7c/0x140
         ? driver_probe_device+0x22/0x1b0
         ? __device_attach_driver+0x13a/0x1c0
         ? __pfx___device_attach_driver+0x10/0x10
         ? bus_for_each_drv+0x114/0x170
         ? __device_attach+0xd6/0x1b0
         ? bus_probe_device+0x9e/0x120
         ? device_add+0x288/0x4b0
         ? platform_device_add+0x75/0x230
         ? platform_device_register_full+0x141/0x180
         ? rust_helper_platform_device_register_simple+0x85/0xb0
         ? _RNvMs2_NtCs1cdwasc6FUb_6kernel8platformNtB5_6Device13create_simple+0x1d/0x60
         ? _RNvXs0_CsHeezP08sTT_5rvkmsNtB5_5RvkmsNtCs1cdwasc6FUb_6kernel6Module4init+0x11e/0x160 [rvkms]
         ? 0xffffffffc083f000
         ? init_module+0x20/0x1000 [rvkms]
         ? kernfs_xattr_get+0x3e/0x80
         ? do_one_initcall+0x148/0x3f0
         ? __lock_acquire+0x5ef/0x2bd0
         ? __lock_acquire+0x5ef/0x2bd0
         ? __lock_acquire+0x5ef/0x2bd0
         ? put_cpu_partial+0x51/0x1d0
         ? lock_acquire+0xec/0x290
         ? put_cpu_partial+0x51/0x1d0
         ? lock_release+0xee/0x310
         ? put_cpu_partial+0x51/0x1d0
         ? fs_reclaim_acquire+0x69/0xf0
         ? lock_acquire+0xec/0x290
         ? fs_reclaim_acquire+0x69/0xf0
         ? kfree+0x22f/0x340
         ? lock_release+0xee/0x310
         ? kmalloc_trace_noprof+0x48/0x340
         ? do_init_module+0x22/0x240
         ? kmalloc_trace_noprof+0x155/0x340
         ? do_init_module+0x60/0x240
         ? __se_sys_finit_module+0x2e0/0x3f0
         ? do_syscall_64+0xa4/0x180
         ? syscall_exit_to_user_mode+0x108/0x140
         ? do_syscall_64+0xb0/0x180
         ? vma_end_read+0xd0/0xe0
         ? do_user_addr_fault+0x309/0x640
         ? clear_bhb_loop+0x45/0xa0
         ? clear_bhb_loop+0x45/0xa0
         ? clear_bhb_loop+0x45/0xa0
         ? entry_SYSCALL_64_after_hwframe+0x76/0x7e
         </TASK>
      
      Fix this by stubbing these macros out when this config option isn't
      enabled, along with fixing the unused variable warning that introduces.
      
      Signed-off-by: Lyude Paul's avatarLyude Paul <lyude@redhat.com>
      7be6db63
    • Lyude Paul's avatar
      rust: sync: Add Guard::from_raw() and from_raw_with() · 10418b86
      Lyude Paul authored
      
      There's a number of APIs in the kernel that have callbacks which occur
      while a specific lock is held. Sometimes these APIs will expect
      implementors to call functions or access state which would otherwise be
      protected by said locks. In order to make writing rust bindings for these
      APIs simpler, let's add a function for unsafely creating a Guard from a raw
      pointer to a lock for contexts where the user already knows a lock is
      acquired. The functions we add for this follow the same lock() and
      lock_with() pattern that we already have for Lock.
      
      Additionally, we make sure these functions actually assert that the lock is
      held already within debugging builds.
      
      Signed-off-by: Lyude Paul's avatarLyude Paul <lyude@redhat.com>
      10418b86
    • Lyude Paul's avatar
      rust: sync: Add lock::Guard aliases outside of this crate · fd2f261c
      Lyude Paul authored
      
      In case someone were to want to return a Guard from a function or use a
      Guard in a custom type, let's expose this outside of just the sync crate.
      This also makes sense since in the next commit, we'll be adding the ability
      to unsafely create Guards in contexts where it is already known that a lock
      is held.
      
      So, add type aliases for all of the different types of guards we might
      encounter.
      
      Signed-off-by: Lyude Paul's avatarLyude Paul <lyude@redhat.com>
      fd2f261c
    • Lyude Paul's avatar
      7d05244c
    • Lyude Paul's avatar
      00f40528
  3. Sep 16, 2024
  4. Sep 12, 2024
    • Alice Ryhl's avatar
      cfi: add CONFIG_CFI_ICALL_NORMALIZE_INTEGERS · ce4a2620
      Alice Ryhl authored
      
      Introduce a Kconfig option for enabling the experimental option to
      normalize integer types. This ensures that integer types of the same
      size and signedness are considered compatible by the Control Flow
      Integrity sanitizer.
      
      The security impact of this flag is minimal. When Sami Tolvanen looked
      into it, he found that integer normalization reduced the number of
      unique type hashes in the kernel by ~1%, which is acceptable.
      
      This option exists for compatibility with Rust, as C and Rust do not
      have the same set of integer types. There are cases where C has two
      different integer types of the same size and signedness, but Rust only
      has one integer type of that size and signedness. When Rust calls into
      C functions using such types in their signature, this results in CFI
      failures. One example is 'unsigned long long' and 'unsigned long' which
      are both 64-bit on LP64 targets, so on those targets this flag will give
      both types the same CFI tag.
      
      This flag changes the ABI heavily. It is not applied automatically when
      CONFIG_RUST is turned on to make sure that the CONFIG_RUST option does
      not change the ABI of C code. For example, some build may need to make
      other changes atomically with toggling this flag. Having it be a
      separate option makes it possible to first turn on normalized integer
      tags, and then later turn on CONFIG_RUST.
      
      Similarly, when turning on CONFIG_RUST in a build, you may need a few
      attempts where the RUST=y commit gets reverted a few times. It is
      inconvenient if reverting RUST=y also requires reverting the changes you
      made to support normalized integer tags.
      
      To avoid having this flag impact builds that don't care about this, the
      next patch in this series will make CONFIG_RUST turn on this option
      using `select` rather than `depends on`.
      
      Signed-off-by: default avatarAlice Ryhl <aliceryhl@google.com>
      Reviewed-by: default avatarSami Tolvanen <samitolvanen@google.com>
      Tested-by: default avatarGatlin Newhouse <gatlin.newhouse@gmail.com>
      Acked-by: default avatarKees Cook <kees@kernel.org>
      Acked-by: default avatarPeter Zijlstra (Intel) <peterz@infradead.org>
      Link: https://lore.kernel.org/r/20240801-kcfi-v2-1-c93caed3d121@google.com
      
      
      Signed-off-by: default avatarMiguel Ojeda <ojeda@kernel.org>
      ce4a2620
    • Alice Ryhl's avatar
      rust: support for shadow call stack sanitizer · d077242d
      Alice Ryhl authored
      
      Add all of the flags that are needed to support the shadow call stack
      (SCS) sanitizer with Rust, and updates Kconfig to allow only
      configurations that work.
      
      The -Zfixed-x18 flag is required to use SCS on arm64, and requires rustc
      version 1.80.0 or greater. This restriction is reflected in Kconfig.
      
      When CONFIG_DYNAMIC_SCS is enabled, the build will be configured to
      include unwind tables in the build artifacts. Dynamic SCS uses the
      unwind tables at boot to find all places that need to be patched. The
      -Cforce-unwind-tables=y flag ensures that unwind tables are available
      for Rust code.
      
      In non-dynamic mode, the -Zsanitizer=shadow-call-stack flag is what
      enables the SCS sanitizer. Using this flag requires rustc version 1.82.0
      or greater on the targets used by Rust in the kernel. This restriction
      is reflected in Kconfig.
      
      It is possible to avoid the requirement of rustc 1.80.0 by using
      -Ctarget-feature=+reserve-x18 instead of -Zfixed-x18. However, this flag
      emits a warning during the build, so this patch does not add support for
      using it and instead requires 1.80.0 or greater.
      
      The dependency is placed on `select HAVE_RUST` to avoid a situation
      where enabling Rust silently turns off the sanitizer. Instead, turning
      on the sanitizer results in Rust being disabled. We generally do not
      want changes to CONFIG_RUST to result in any mitigations being changed
      or turned off.
      
      At the time of writing, rustc 1.82.0 only exists via the nightly release
      channel. There is a chance that the -Zsanitizer=shadow-call-stack flag
      will end up needing 1.83.0 instead, but I think it is small.
      
      Reviewed-by: default avatarSami Tolvanen <samitolvanen@google.com>
      Reviewed-by: default avatarArd Biesheuvel <ardb@kernel.org>
      Reviewed-by: default avatarKees Cook <kees@kernel.org>
      Acked-by: default avatarWill Deacon <will@kernel.org>
      Signed-off-by: default avatarAlice Ryhl <aliceryhl@google.com>
      Link: https://lore.kernel.org/r/20240829-shadow-call-stack-v7-1-2f62a4432abf@google.com
      
      
      [ Fixed indentation using spaces. - Miguel ]
      Signed-off-by: default avatarMiguel Ojeda <ojeda@kernel.org>
      d077242d
    • Lyude Paul's avatar
      Merge branch 'hrtimer-v2-6.11-wip' of github.com:metaspace/linux into rvkms-base · 8d2749cd
      Lyude Paul authored
      Merge Andreas's hrtimer work
      8d2749cd
    • Lyude Paul's avatar
      Merge remote-tracking branch 'drm-misc/topic/rust-drm' into rvkms-base · 3f2fe398
      Lyude Paul authored
      Note: I had to split out basically all of the rust C helpers into separate
      files, so there's a number of changes here
      3f2fe398
    • Lyude Paul's avatar
      Merge branch 'vtable-wip' of github.com:nbdd0121/linux into rvkms-base · aa73360c
      Lyude Paul authored
      For #[unique] macro support
      aa73360c
    • Andreas Hindborg's avatar
      Add `PinTimerHandle` · 42eeef0f
      Andreas Hindborg authored
      42eeef0f
    • Andreas Hindborg's avatar
      Refactor example · be325952
      Andreas Hindborg authored
      be325952
    • Andreas Hindborg's avatar
      79297ecf
Loading