lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <8734diq7o3.fsf@kernel.org>
Date: Tue, 06 May 2025 13:51:08 +0200
From: Andreas Hindborg <a.hindborg@...nel.org>
To: "Miguel Ojeda" <miguel.ojeda.sandonis@...il.com>
Cc: "Danilo Krummrich" <dakr@...nel.org>,  "Miguel Ojeda"
 <ojeda@...nel.org>,  "Alex Gaynor" <alex.gaynor@...il.com>,  "Boqun Feng"
 <boqun.feng@...il.com>,  "Gary Guo" <gary@...yguo.net>,  Björn Roy Baron
 <bjorn3_gh@...tonmail.com>,  "Benno Lossin" <benno.lossin@...ton.me>,
  "Alice Ryhl" <aliceryhl@...gle.com>,  "Trevor Gross" <tmgross@...ch.edu>,
  "Joel Becker" <jlbec@...lplan.org>,  "Peter Zijlstra"
 <peterz@...radead.org>,  "Ingo Molnar" <mingo@...hat.com>,  "Will Deacon"
 <will@...nel.org>,  "Waiman Long" <longman@...hat.com>,  "Fiona Behrens"
 <me@...enk.dev>,  "Charalampos Mitrodimas" <charmitro@...teo.net>,
  "Daniel Almeida" <daniel.almeida@...labora.com>,  "Breno Leitao"
 <leitao@...ian.org>,  <rust-for-linux@...r.kernel.org>,
  <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v6 1/3] rust: configfs: introduce rust support for configfs

Andreas Hindborg <a.hindborg@...nel.org> writes:

> "Miguel Ojeda" <miguel.ojeda.sandonis@...il.com> writes:
>
>> On Mon, May 5, 2025 at 9:51 AM Andreas Hindborg <a.hindborg@...nel.org> wrote:
>>>
>>> So I was thinking that because I am initializing a static with a let
>>> statement, it would run in const context. But I see that it is not
>>> actually guaranteed.
>>
>> No, that is actually guaranteed, i.e. when initializing a static. But
>> you aren't initializing a static here, no? Which static are you
>> referring to? If you were, then the "normal" `assert!` would work,
>> because it would be a const context.
>>
>> The `add` calls I see are just in the `let` statement, not
>> initializing any static:
>>
>>             {
>>                 const N: usize = 0usize;
>>                 unsafe { CONFIGURATION_ATTRS.add::<N, 0,
>> _>(&CONFIGURATION_MESSAGE_ATTR) };
>>             }
>>
>> So it also means this comment is wrong:
>>
>> +        // SAFETY: This function is only called through the `configfs_attrs`
>> +        // macro. This ensures that we are evaluating the function in const
>> +        // context when initializing a static. As such, the reference created
>> +        // below will be exclusive.
>>
>> Please double-check all this... :)
>
> Oops.
>
>>
>>> Right. Which is why I opted for `build_error`. But with the `const`
>>> block solution you suggested is better.
>>
>> I thought you opted for that because you thought the `assert!` would
>> only work if not refactored. What I tried to point out was that the
>> `assert!` wouldn't have worked even before the refactoring.
>
> I made a mistake in thinking this was in const context. I'll see if I
> can fix that.


I think I can fix it like this:


modified   rust/kernel/configfs.rs
@@ -703,8 +703,8 @@ impl<const N: usize, Data> AttributeList<N, Data> {
 
     /// # Safety
     ///
-    /// This function can only be called by the [`kernel::configfs_attrs`]
-    /// macro.
+    /// The caller must ensure that there are no other concurrent accesses to
+    /// `self`. That is, the caller has exclusive access to `self.`
     #[doc(hidden)]
     pub const unsafe fn add<const I: usize, const ID: u64, O>(
         &'static self,
@@ -715,10 +715,8 @@ impl<const N: usize, Data> AttributeList<N, Data> {
         // We need a space at the end of our list for a null terminator.
         const { assert!(I < N - 1, "Invalid attribute index") };
 
-        // SAFETY: This function is only called through the
-        // [kernel::`configfs_attrs`] macro. This ensures that we are evaluating
-        // the function in const context when initializing a static. As such,
-        // the reference created below will be exclusive.
+        // SAFETY: By function safety requirements, we have exclusive access to
+        // `self` and the reference created below will be exclusive.
         unsafe {
             (&mut *self.0.get())[I] = (attribute as *const Attribute<ID, O, Data>)
                 .cast_mut()
@@ -955,7 +953,12 @@ macro_rules! configfs_attrs {
             @assign($($assign)* {
                 const N: usize = $cnt;
                 // The following macro text expands to a call to `Attribute::add`.
-                // SAFETY: We are expanding [`kernel::configfs_attrs`].
+
+                // SAFETY: By design of this macro, the name of the variable we
+                // invoke the `add` method on below, is not visible outside of
+                // the macro expansion. The macro does not operate concurrently
+                // on this variable, and thus we have exclusive access to the
+                // variable.
                 unsafe {
                     $crate::macros::paste!(
                         [< $data:upper _ATTRS >]


Best regards,
Andreas Hindborg



Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ