- Sep 30, 2024
-
-
Lyude Paul authored
TODO: turn this into its own commit in preparation for making Guard::new() public
-
Lyude Paul authored
This doesnt' really matter though, since we already decided from_raw() is a bad idea when we can just from_raw the actual lock instead
-
Lyude Paul authored
Since we have the ability to retrieve Lock structures from raw C structures now, we also want the ability to do so for guards - as this can be useful in the context of C callbacks where we know that a lock is already held, and may need to take advantage of that to perform operations under said lock. So, let's make Guard::new() a public function. Additionally, let's also add a Guard::new_with() function to match the lock() and lock_with() pattern that we currently have with locks. This way users get the additional protection of associating the lifetime of the lock context with the Guard even in unsafe contexts. Signed-off-by:
Lyude Paul <lyude@redhat.com>
-
Lyude Paul authored
Signed-off-by:
Lyude Paul <lyude@redhat.com>
-
Create an abstraction to allow Rust drivers to open a new devres group for the device with a defined id. Moreover, implement the related Drop trait to release the devres group. [Lyude: cherry picked from 8e57c7d478ddeabe61c53b6dd01fd326e3256221 from https://github.com/mairacanal/linux/pull/11 ] Signed-off-by:
Maíra Canal <mcanal@igalia.com> [Rebased] Signed-off-by:
Lyude Paul <lyude@redhat.com>
-
Currently, platform device holds only a pointer, which is safe to be used from any thread. This is useful for devices that are not probed, such as virtual devices. [Lyude: cherry-picked from 9a6a07a9828ea840194c8428d45cd54d5c386265 https://github.com/mairacanal/linux/tree/vgem/wip-dma ] Signed-off-by:
Maíra Canal <mcanal@igalia.com>
-
The DRM shmem helper includes common code useful for drivers which allocate GEM objects as anonymous shmem. Add a Rust abstraction for this. Drivers can choose the raw GEM implementation or the shmem layer, depending on their needs. Lyude changelog: * Rebase * Squash "rust: drm: device: Convert Device to AlwaysRefCounted" as this commit doesn't compile without it anyway Signed-off-by:
Asahi Lina <lina@asahilina.net>
-
There doesn't seem to be a way for the Rust bindings to get a compile-time constant reference to drm_gem_shmem_vm_ops, so we need to duplicate that structure in Rust... this isn't nice... Signed-off-by:
Asahi Lina <lina@asahilina.net>
-
This is just for basic usage in the DRM shmem abstractions for implied locking, not intended as a full DMA Reservation abstraction yet. Signed-off-by:
Asahi Lina <lina@asahilina.net>
-
Lyude Paul authored
While working on rvkms, I noticed that there's no code that actually uses the drm_pending_vblank_event that's embedded in vkms_output. So, just drop the member from the struct. Signed-off-by:
Lyude Paul <lyude@redhat.com>
-
Lyude Paul authored
Something I discovered while writing rvkms since some versions of the driver didn't have a filled out atomic_update function - we mention that this callback is "optional", but we don't actually check whether it's NULL or not before calling it. As a result, we'll segfault if it's not filled in. rvkms rvkms.0: [drm:drm_atomic_helper_commit_modeset_disables] modeset on [ENCODER:36:Virtual-36] BUG: kernel NULL pointer dereference, address: 0000000000000000 PGD 0 P4D 0 Oops: Oops: 0010 [#1] PREEMPT SMP NOPTI Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS edk2-20240813-1.fc40 08/13/2024 RIP: 0010:0x0 So, let's fix that. Signed-off-by:
Lyude Paul <lyude@redhat.com>
-
Lyude Paul authored
Currently, there's nothing actually stopping a driver from only registering vblank support for some of it's CRTCs and not for others. As far as I can tell, this isn't really defined behavior on the C side of things - as the documentation explicitly mentions to not use drm_vblank_init() if you don't have vblank support - since DRM then steps in and adds its own vblank emulation implementation. So, let's fix this edge case and check to make sure it's all or none. Signed-off-by:
Lyude Paul <lyude@redhat.com>
-
Lyude Paul authored
This needs to be cleaned up and I need to start upstreaming this…
-
Lyude Paul authored
TODO: * The idea for this came from Maíra originally, and they should probably be the commit author (we'll fix that before final submission because credit is important :3, right now it's just a bit easier to rewrite the commit)
-
Commit reference: 3dfc5ebff103 Lyude: Any interfaces not currently use or anticipated to be used by rvkms have been dropped. This includes pretty much all of the devicetree (of) references. Changes: * Rebase against rust-next for the helpers.c changes
-
Based on https://github.com/wedsonaf/linux/commit/02541e65a7e778c0049fed86ae49302bc07abed3 TODO: * All of these are currently missing documentation. We'll add that later once we have a better idea of what we'll all need.
-
- Sep 20, 2024
-
-
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 <lyude@redhat.com>
-
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 <lyude@redhat.com>
-
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 <lyude@redhat.com>
-
Lyude Paul authored
-
Lyude Paul authored
-
- Sep 16, 2024
-
-
Lyude Paul authored
A few of the APIs I've been writing bindings for (KMS in particular) rely on the user manually acquiring specific locks before calling certain functions. At the moment though, the only way of acquiring these locks in bindings is to simply call the C locking functions directly - since said locks are not acquired on the rust side of things. However - if we add `#[repr(C)]` to `Lock<(), B>`, then given `()` is a ZST - `Lock<(), B>` becomes equivalent in data layout to its inner `B::State` type. Since locks in C don't have data explicitly associated with them anyway, we can take advantage of this to add a `Lock::from_raw()` function that can translate a raw pointer to `B::State` into its proper `Lock<(), B>` equivalent. This lets us simply acquire a reference to the lock in question and work with it like it was initialized on the rust side of things, allowing us to use less unsafe code to implement bindings with lock requirements. Signed-off-by:
Lyude Paul <lyude@redhat.com> --- V2: * Don't implement this for all ZST types, just implement it for ()
-
Lyude Paul authored
A variant of SpinLock that is expected to be used in noirq contexts, and thus requires that the user provide an kernel::irq::IrqDisabled to prove they are in such a context upon lock acquisition. This is the rust equivalent of spin_lock_irqsave()/spin_lock_irqrestore(). Signed-off-by:
Lyude Paul <lyude@redhat.com> Reviewed-by:
Benno Lossin <benno.lossin@proton.me> Reviewed-by:
Daniel Almeida <daniel.almeida@collabora.com> Reviewed-by:
Gary Guo <gary@garyguo.net> --- V2: * s/IrqSpinLock/SpinLockIrq/ * Implement `lock::Backend` now that we have `Context` * Add missing periods * Make sure rustdoc examples compile correctly * Add documentation suggestions
-
Lyude Paul authored
Now that we've introduced an `IrqDisabled` token for marking contexts in which IRQs are disabled, we need a way to be able to pass it to locks that require that IRQs are disabled. In order to continue using the `lock::Backend` type instead of inventing our own thing, we accomplish this by adding the associated Context type, along with a `lock_with()` function that can accept a Context when acquiring a lock. To allow current users of context-less locks to keep using the normal `lock()` method, we take an example from Wedson Almeida Filho's work and add a `where T<'a>: Default` bound to `lock()` so that it can only be called on lock types where the context is simply a placeholder value, then re-implement it through the new `lock_with()` function. Signed-off-by:
Lyude Paul <lyude@redhat.com> Reviewed-by:
Benno Lossin <benno.lossin@proton.me> Reviewed-by:
Daniel Almeida <daniel.almeida@collabora.com> Reviewed-by:
Gary Guo <gary@garyguo.net> --- V3: * Use explicit lifetimes in lock_with() to ensure self and _context have the same lifetime (Benno) * Use () for locks that don't need a Context instead of PhantomData (Benno) V4: * Fix typo (Dirk)
-
Lyude Paul authored
This introduces a module for dealing with interrupt-disabled contexts, including the ability to enable and disable interrupts (with_irqs_disabled()) - along with the ability to annotate functions as expecting that IRQs are already disabled on the local CPU. Signed-off-by:
Lyude Paul <lyude@redhat.com> Reviewed-by:
Benno Lossin <benno.lossin@proton.me> Reviewed-by:
Daniel Almeida <daniel.almeida@collabora.com> Reviewed-by:
Gary Guo <gary@garyguo.net> --- V2: * Actually make it so that we check whether or not we have interrupts disabled with debug assertions * Fix issues in the documentation (added suggestions, missing periods, made sure that all rustdoc examples compile properly) * Pass IrqDisabled by value, not reference * Ensure that IrqDisabled is !Send and !Sync using PhantomData<(&'a (), *mut ())> * Add all of the suggested derives from Benno Lossin V3: * Use `impl` for FnOnce bounds in with_irqs_disabled() * Use higher-ranked trait bounds for the lifetime of with_irqs_disabled() * Wording changes in the documentation for the module itself V4: * Use the actual unsafe constructor for IrqDisabled in with_irqs_disabled() * Fix comment style in with_irqs_disabled example * Check before calling local_irq_restore() in with_irqs_disabled that interrupts are still disabled. It would have been nice to do this from a Drop implementation like I hoped, but I realized rust doesn't allow that for types that implement Copy. * Document that interrupts can't be re-enabled within the `cb` provided to `with_irqs_disabled`, and link to the github issue I just filed about this that describes the solution for this. V5: * Rebase against rust-next for the helpers split * Fix typo (enabled -> disabled) - Dirk V6: * s/indicate/require/ in IrqDisabled docs * Reword comment above with_irqs_disabled in code example requested by Benno * Add paragraph to with_irqs_disabled docs requested by Benno * Apply the comments from Boqun's review for V4 that I missed * Document type invariants of `IrqDisabled` This patch depends on https://lore.kernel.org/rust-for-linux/ZuKNszXSw-LbgW1e@boqun-archlinux/
-
This introduces a new marker type for types that shouldn't be thread safe. By adding a field of this type to a struct, it becomes non-Send and non-Sync, which means that it cannot be accessed in any way from threads other than the one it was created on. This is useful for APIs that require globals such as `current` to remain constant while the value exists. We update two existing users in the Kernel to use this helper: * `Task::current()` - moving the return type of this value to a different thread would not be safe as you can no longer be guaranteed that the `current` pointer remains valid. * Lock guards. Mutexes and spinlocks should be unlocked on the same thread as where they were locked, so we enforce this using the Send trait. There are also additional users in later patches of this patchset. See [1] and [2] for the discussion that led to the introduction of this patch. Link: https://lore.kernel.org/all/nFDPJFnzE9Q5cqY7FwSMByRH2OAn_BpI4H53NQfWIlN6I2qfmAqnkp2wRqn0XjMO65OyZY4h6P4K2nAGKJpAOSzksYXaiAK_FoH_8QbgBI4=@proton.me/ [1] Link: https://lore.kernel.org/all/nFDPJFnzE9Q5cqY7FwSMByRH2OAn_BpI4H53NQfWIlN6I2qfmAqnkp2wRqn0XjMO65OyZY4h6P4K2nAGKJpAOSzksYXaiAK_FoH_8QbgBI4=@proton.me/ [2] Suggested-by:
Benno Lossin <benno.lossin@proton.me> Reviewed-by:
Benno Lossin <benno.lossin@proton.me> Reviewed-by:
Trevor Gross <tmgross@umich.edu> Reviewed-by:
Martin Rodriguez Reboredo <yakoyoku@gmail.com> Reviewed-by:
Björn Roy Baron <bjorn3_gh@protonmail.com> Reviewed-by:
Gary Guo <gary@garyguo.net> Signed-off-by:
Alice Ryhl <aliceryhl@google.com>
-
Matthew Maurer authored
Adds a smoke test to ensure that KASAN in Rust is actually detecting a Rust-native UAF. There is significant room to expand this test suite, but this will at least ensure that flags are having the intended effect. The rename from kasan_test.c to kasan_test_c.c is in order to allow the single kasan_test.ko test suite to contain both a .o file produced by the C compiler and one produced by rustc. Signed-off-by:
Matthew Maurer <mmaurer@google.com> Reviewed-by:
Andrey Konovalov <andreyknvl@gmail.com> Link: https://lore.kernel.org/r/20240820194910.187826-5-mmaurer@google.com [ Applied empty line nit, removed double empty line, applied `rustfmt` and formatted crate comment. - Miguel ] Signed-off-by:
Miguel Ojeda <ojeda@kernel.org>
-
Matthew Maurer authored
Rust supports KASAN via LLVM, but prior to this patch, the flags aren't set properly. Suggested-by:
Miguel Ojeda <ojeda@kernel.org> Signed-off-by:
Matthew Maurer <mmaurer@google.com> Reviewed-by:
Andrey Konovalov <andreyknvl@gmail.com> Link: https://lore.kernel.org/r/20240820194910.187826-4-mmaurer@google.com [ Applied "SW_TAGS KASAN" nit. - Miguel ] Signed-off-by:
Miguel Ojeda <ojeda@kernel.org>
-
Matthew Maurer authored
Rust does not yet have support for software tags. Prevent RUST from being selected if KASAN_SW_TAGS is enabled. Signed-off-by:
Matthew Maurer <mmaurer@google.com> Reviewed-by:
Andrey Konovalov <andreyknvl@gmail.com> Link: https://lore.kernel.org/r/20240820194910.187826-3-mmaurer@google.com Signed-off-by:
Miguel Ojeda <ojeda@kernel.org>
-
Matthew Maurer authored
Creates flag probe macro variants for `rustc`. These are helpful because: 1. The kernel now supports a minimum `rustc` version rather than a single version. 2. `rustc` links against a range of LLVM revisions, occasionally even ones without an official release number. Since the availability of some Rust flags depends on which LLVM it has been linked against, probing is necessary. Signed-off-by:
Matthew Maurer <mmaurer@google.com> Link: https://github.com/Rust-for-Linux/linux/pull/1087 Link: https://lore.kernel.org/r/20240820194910.187826-2-mmaurer@google.com Signed-off-by:
Miguel Ojeda <ojeda@kernel.org>
-
Andrey Konovalov authored
When KASAN support was being added to the Linux kernel, GCC did not yet support all of the KASAN-related compiler options. Thus, the KASAN Makefile had to probe the compiler for supported options. Nowadays, the Linux kernel GCC version requirement is 5.1+, and thus we don't need the probing of the -fasan-shadow-offset parameter: it exists in all 5.1+ GCCs. Simplify the KASAN Makefile to drop CFLAGS_KASAN_MINIMAL. Also add a few more comments and unify the indentation. Signed-off-by:
Andrey Konovalov <andreyknvl@gmail.com> Acked-by:
Marco Elver <elver@google.com> Link: https://lore.kernel.org/r/20240814161052.10374-1-andrey.konovalov@linux.dev Signed-off-by:
Miguel Ojeda <ojeda@kernel.org>
-
Matthew Maurer authored
Make it possible to use the Control Flow Integrity (CFI) sanitizer when Rust is enabled. Enabling CFI with Rust requires that CFI is configured to normalize integer types so that all integer types of the same size and signedness are compatible under CFI. Rust and C use the same LLVM backend for code generation, so Rust KCFI is compatible with the KCFI used in the kernel for C. In the case of FineIBT, CFI also depends on -Zpatchable-function-entry for rewriting the function prologue, so we set that flag for Rust as well. The flag for FineIBT requires rustc 1.80.0 or later, so include a Kconfig requirement for that. Enabling Rust will select CFI_ICALL_NORMALIZE_INTEGERS because the flag is required to use Rust with CFI. Using select rather than `depends on` avoids the case where Rust is not visible in menuconfig due to CFI_ICALL_NORMALIZE_INTEGERS not being enabled. One disadvantage of select is that RUST must `depends on` all of the things that CFI_ICALL_NORMALIZE_INTEGERS depends on to avoid invalid configurations. Alice has been using KCFI on her phone for several months, so it is reasonably well tested on arm64. Signed-off-by:
Matthew Maurer <mmaurer@google.com> Co-developed-by:
Alice Ryhl <aliceryhl@google.com> Signed-off-by:
Alice Ryhl <aliceryhl@google.com> Reviewed-by:
Sami Tolvanen <samitolvanen@google.com> Tested-by:
Gatlin Newhouse <gatlin.newhouse@gmail.com> Acked-by:
Kees Cook <kees@kernel.org> Acked-by:
Peter Zijlstra (Intel) <peterz@infradead.org> Link: https://lore.kernel.org/r/20240801-kcfi-v2-2-c93caed3d121@google.com [ Replaced `!FINEIBT` requirement with `!CALL_PADDING` to prevent a build error on older Rust compilers. Fixed typo. - Miguel ] Signed-off-by:
Miguel Ojeda <ojeda@kernel.org>
-
- Sep 12, 2024
-
-
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:
Alice Ryhl <aliceryhl@google.com> Reviewed-by:
Sami Tolvanen <samitolvanen@google.com> Tested-by:
Gatlin Newhouse <gatlin.newhouse@gmail.com> Acked-by:
Kees Cook <kees@kernel.org> Acked-by:
Peter Zijlstra (Intel) <peterz@infradead.org> Link: https://lore.kernel.org/r/20240801-kcfi-v2-1-c93caed3d121@google.com Signed-off-by:
Miguel Ojeda <ojeda@kernel.org>
-
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:
Sami Tolvanen <samitolvanen@google.com> Reviewed-by:
Ard Biesheuvel <ardb@kernel.org> Reviewed-by:
Kees Cook <kees@kernel.org> Acked-by:
Will Deacon <will@kernel.org> Signed-off-by:
Alice 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:
Miguel Ojeda <ojeda@kernel.org>
-
Lyude Paul authored
Merge Andreas's hrtimer work
-
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
-
Lyude Paul authored
For #[unique] macro support
-
Andreas Hindborg authored
-
Andreas Hindborg authored
-
Andreas Hindborg authored
-