| Message ID | 20241101095620.2526421-1-aliceryhl@google.com (mailing list archive) |
|---|---|
| State | Under Review |
| Delegated to: | Paul Moore |
| Headers | show |
| Series | rust: lsm: replace context+len with lsm_context | expand |
On Fri, Nov 1, 2024 at 5:56 AM Alice Ryhl <aliceryhl@google.com> wrote: > > This brings the Rust SecurityCtx abstraction [1] up to date with the new > API where context+len is replaced with an lsm_context [2] struct. > > Link: https://lore.kernel.org/r/20240915-alice-file-v10-5-88484f7a3dcf@google.com [1] > Link: https://lore.kernel.org/r/20241023212158.18718-3-casey@schaufler-ca.com [2] > Reported-by: Linux Kernel Functional Testing <lkft@linaro.org> > Closes: https://lore.kernel.org/r/CA+G9fYv_Y2tzs+uYhMGtfUK9dSYV2mFr6WyKEzJazDsdk9o5zw@mail.gmail.com > Signed-off-by: Alice Ryhl <aliceryhl@google.com> > --- > rust/helpers/security.c | 8 ++++---- > rust/kernel/security.rs | 38 +++++++++++++++++--------------------- > 2 files changed, 21 insertions(+), 25 deletions(-) Thanks Alice. Would you like me to pull this in via the LSM tree with the associated LSM changes, or would you prefer to do this some other way? I'm going to merge this into lsm/dev for now so that we fix the issue in linux-next, but I'm happy to drop it or do something else, let me know.
On Fri, Nov 1, 2024 at 12:56 PM Paul Moore <paul@paul-moore.com> wrote: > On Fri, Nov 1, 2024 at 5:56 AM Alice Ryhl <aliceryhl@google.com> wrote: > > > > This brings the Rust SecurityCtx abstraction [1] up to date with the new > > API where context+len is replaced with an lsm_context [2] struct. > > > > Link: https://lore.kernel.org/r/20240915-alice-file-v10-5-88484f7a3dcf@google.com [1] > > Link: https://lore.kernel.org/r/20241023212158.18718-3-casey@schaufler-ca.com [2] > > Reported-by: Linux Kernel Functional Testing <lkft@linaro.org> > > Closes: https://lore.kernel.org/r/CA+G9fYv_Y2tzs+uYhMGtfUK9dSYV2mFr6WyKEzJazDsdk9o5zw@mail.gmail.com > > Signed-off-by: Alice Ryhl <aliceryhl@google.com> > > --- > > rust/helpers/security.c | 8 ++++---- > > rust/kernel/security.rs | 38 +++++++++++++++++--------------------- > > 2 files changed, 21 insertions(+), 25 deletions(-) > > Thanks Alice. Would you like me to pull this in via the LSM tree with > the associated LSM changes, or would you prefer to do this some other > way? > > I'm going to merge this into lsm/dev for now so that we fix the issue > in linux-next, but I'm happy to drop it or do something else, let me > know. Nevermind, no I'm not, as I don't have the LSM/security rust helpers in the LSM tree as it looks like those aren't in Linus' tree yet.
On Fri, Nov 1, 2024 at 5:56 PM Paul Moore <paul@paul-moore.com> wrote: > > Thanks Alice. Would you like me to pull this in via the LSM tree with > the associated LSM changes, or would you prefer to do this some other > way? > > I'm going to merge this into lsm/dev for now so that we fix the issue > in linux-next, but I'm happy to drop it or do something else, let me > know. Christian has the VFS side, and both are needed for this -- do you mean you will cross-merge vfs' branch too? By the way, merging both vfs.rust.file and lsm/dev I confirm this builds fine: Acked-by: Miguel Ojeda <ojeda@kernel.org> Thanks! Cheers, Miguel
On Fri, Nov 1, 2024 at 1:04 PM Miguel Ojeda <miguel.ojeda.sandonis@gmail.com> wrote: > On Fri, Nov 1, 2024 at 5:56 PM Paul Moore <paul@paul-moore.com> wrote: > > > > Thanks Alice. Would you like me to pull this in via the LSM tree with > > the associated LSM changes, or would you prefer to do this some other > > way? > > > > I'm going to merge this into lsm/dev for now so that we fix the issue > > in linux-next, but I'm happy to drop it or do something else, let me > > know. > > Christian has the VFS side, and both are needed for this -- do you > mean you will cross-merge vfs' branch too? I think our last emails crossed paths. I'm not going to merge this via the LSM tree as we don't have the Rust security.c helpers. Ideally it would have been better to have the Rust LSM/security helpers in the LSM tree for reasons like this, but it looks like it's too late for that now. > By the way, merging both vfs.rust.file and lsm/dev I confirm this builds fine: > > Acked-by: Miguel Ojeda <ojeda@kernel.org> Thanks for the build test!
On Fri, Nov 1, 2024 at 6:11 PM Paul Moore <paul@paul-moore.com> wrote: > > On Fri, Nov 1, 2024 at 1:04 PM Miguel Ojeda > <miguel.ojeda.sandonis@gmail.com> wrote: > > On Fri, Nov 1, 2024 at 5:56 PM Paul Moore <paul@paul-moore.com> wrote: > > > > > > Thanks Alice. Would you like me to pull this in via the LSM tree with > > > the associated LSM changes, or would you prefer to do this some other > > > way? > > > > > > I'm going to merge this into lsm/dev for now so that we fix the issue > > > in linux-next, but I'm happy to drop it or do something else, let me > > > know. > > > > Christian has the VFS side, and both are needed for this -- do you > > mean you will cross-merge vfs' branch too? > > I think our last emails crossed paths. I'm not going to merge this > via the LSM tree as we don't have the Rust security.c helpers. > Ideally it would have been better to have the Rust LSM/security > helpers in the LSM tree for reasons like this, but it looks like it's > too late for that now. If Christian is okay with rewriting the vfs.rust.file tree, we can drop commit 94d356c0335f ("rust: security: add abstraction for secctx") from there and I'll update it and send it for inclusion in the LSM tree instead. I'll need to drop the piece that ties together `struct cred` and `secctx` from the patch, but I can follow up with a small patch for that for the 6.14 merge window. Alice
On Fri, Nov 1, 2024 at 1:24 PM Alice Ryhl <aliceryhl@google.com> wrote: > On Fri, Nov 1, 2024 at 6:11 PM Paul Moore <paul@paul-moore.com> wrote: > > On Fri, Nov 1, 2024 at 1:04 PM Miguel Ojeda > > <miguel.ojeda.sandonis@gmail.com> wrote: > > > On Fri, Nov 1, 2024 at 5:56 PM Paul Moore <paul@paul-moore.com> wrote: > > > > > > > > Thanks Alice. Would you like me to pull this in via the LSM tree with > > > > the associated LSM changes, or would you prefer to do this some other > > > > way? > > > > > > > > I'm going to merge this into lsm/dev for now so that we fix the issue > > > > in linux-next, but I'm happy to drop it or do something else, let me > > > > know. > > > > > > Christian has the VFS side, and both are needed for this -- do you > > > mean you will cross-merge vfs' branch too? > > > > I think our last emails crossed paths. I'm not going to merge this > > via the LSM tree as we don't have the Rust security.c helpers. > > Ideally it would have been better to have the Rust LSM/security > > helpers in the LSM tree for reasons like this, but it looks like it's > > too late for that now. > > If Christian is okay with rewriting the vfs.rust.file tree, we can > drop commit 94d356c0335f ("rust: security: add abstraction for > secctx") from there and I'll update it and send it for inclusion in > the LSM tree instead. I'll need to drop the piece that ties together > `struct cred` and `secctx` from the patch, but I can follow up with a > small patch for that for the 6.14 merge window. I can only guess at what Chrisitian wants to do, but my guess is that he isn't going to be very excited about rewriting a VFS tree at this stage ... which is very understandable as far as I'm concerned. I wouldn't worry too much about this right now, I'm going to plan on holding Casey's patchset in a staging area until after the upcoming merge window.
On Fri, Nov 1, 2024 at 6:59 PM Paul Moore <paul@paul-moore.com> wrote: > > On Fri, Nov 1, 2024 at 1:24 PM Alice Ryhl <aliceryhl@google.com> wrote: > > On Fri, Nov 1, 2024 at 6:11 PM Paul Moore <paul@paul-moore.com> wrote: > > > On Fri, Nov 1, 2024 at 1:04 PM Miguel Ojeda > > > <miguel.ojeda.sandonis@gmail.com> wrote: > > > > On Fri, Nov 1, 2024 at 5:56 PM Paul Moore <paul@paul-moore.com> wrote: > > > > > > > > > > Thanks Alice. Would you like me to pull this in via the LSM tree with > > > > > the associated LSM changes, or would you prefer to do this some other > > > > > way? > > > > > > > > > > I'm going to merge this into lsm/dev for now so that we fix the issue > > > > > in linux-next, but I'm happy to drop it or do something else, let me > > > > > know. > > > > > > > > Christian has the VFS side, and both are needed for this -- do you > > > > mean you will cross-merge vfs' branch too? > > > > > > I think our last emails crossed paths. I'm not going to merge this > > > via the LSM tree as we don't have the Rust security.c helpers. > > > Ideally it would have been better to have the Rust LSM/security > > > helpers in the LSM tree for reasons like this, but it looks like it's > > > too late for that now. > > > > If Christian is okay with rewriting the vfs.rust.file tree, we can > > drop commit 94d356c0335f ("rust: security: add abstraction for > > secctx") from there and I'll update it and send it for inclusion in > > the LSM tree instead. I'll need to drop the piece that ties together > > `struct cred` and `secctx` from the patch, but I can follow up with a > > small patch for that for the 6.14 merge window. > > I can only guess at what Chrisitian wants to do, but my guess is that > he isn't going to be very excited about rewriting a VFS tree at this > stage ... which is very understandable as far as I'm concerned. > > I wouldn't worry too much about this right now, I'm going to plan on > holding Casey's patchset in a staging area until after the upcoming > merge window. Okay. If Casey's patchset is not landing for 6.13, then the fix I posted initially can be used. Casey is also welcome to squash my fix into his series if you all prefer that. I'm happy with whatever is easiest for you all. Alice
diff --git a/rust/helpers/security.c b/rust/helpers/security.c index 239e5b4745fe..0c4c2065df28 100644 --- a/rust/helpers/security.c +++ b/rust/helpers/security.c @@ -8,13 +8,13 @@ void rust_helper_security_cred_getsecid(const struct cred *c, u32 *secid) security_cred_getsecid(c, secid); } -int rust_helper_security_secid_to_secctx(u32 secid, char **secdata, u32 *seclen) +int rust_helper_security_secid_to_secctx(u32 secid, struct lsm_context *cp) { - return security_secid_to_secctx(secid, secdata, seclen); + return security_secid_to_secctx(secid, cp); } -void rust_helper_security_release_secctx(char *secdata, u32 seclen) +void rust_helper_security_release_secctx(struct lsm_context *cp) { - security_release_secctx(secdata, seclen); + security_release_secctx(cp); } #endif diff --git a/rust/kernel/security.rs b/rust/kernel/security.rs index 2522868862a1..25d2b1ac3833 100644 --- a/rust/kernel/security.rs +++ b/rust/kernel/security.rs @@ -15,60 +15,56 @@ /// /// # Invariants /// -/// The `secdata` and `seclen` fields correspond to a valid security context as returned by a -/// successful call to `security_secid_to_secctx`, that has not yet been destroyed by calling -/// `security_release_secctx`. +/// The `ctx` field corresponds to a valid security context as returned by a successful call to +/// `security_secid_to_secctx`, that has not yet been destroyed by `security_release_secctx`. pub struct SecurityCtx { - secdata: *mut core::ffi::c_char, - seclen: usize, + ctx: bindings::lsm_context, } impl SecurityCtx { /// Get the security context given its id. pub fn from_secid(secid: u32) -> Result<Self> { - let mut secdata = core::ptr::null_mut(); - let mut seclen = 0u32; - // SAFETY: Just a C FFI call. The pointers are valid for writes. - to_result(unsafe { bindings::security_secid_to_secctx(secid, &mut secdata, &mut seclen) })?; + // SAFETY: `struct lsm_context` can be initialized to all zeros. + let mut ctx: bindings::lsm_context = unsafe { core::mem::zeroed() }; + + // SAFETY: Just a C FFI call. The pointer is valid for writes. + to_result(unsafe { bindings::security_secid_to_secctx(secid, &mut ctx) })?; // INVARIANT: If the above call did not fail, then we have a valid security context. - Ok(Self { - secdata, - seclen: seclen as usize, - }) + Ok(Self { ctx }) } /// Returns whether the security context is empty. pub fn is_empty(&self) -> bool { - self.seclen == 0 + self.ctx.len == 0 } /// Returns the length of this security context. pub fn len(&self) -> usize { - self.seclen + self.ctx.len as usize } /// Returns the bytes for this security context. pub fn as_bytes(&self) -> &[u8] { - let ptr = self.secdata; + let ptr = self.ctx.context; if ptr.is_null() { - debug_assert_eq!(self.seclen, 0); + debug_assert_eq!(self.len(), 0); // We can't pass a null pointer to `slice::from_raw_parts` even if the length is zero. return &[]; } // SAFETY: The call to `security_secid_to_secctx` guarantees that the pointer is valid for - // `seclen` bytes. Furthermore, if the length is zero, then we have ensured that the + // `self.len()` bytes. Furthermore, if the length is zero, then we have ensured that the // pointer is not null. - unsafe { core::slice::from_raw_parts(ptr.cast(), self.seclen) } + unsafe { core::slice::from_raw_parts(ptr.cast(), self.len()) } } } impl Drop for SecurityCtx { fn drop(&mut self) { - // SAFETY: By the invariant of `Self`, this frees a pointer that came from a successful + // SAFETY: By the invariant of `Self`, this frees a context that came from a successful // call to `security_secid_to_secctx` and has not yet been destroyed by // `security_release_secctx`. - unsafe { bindings::security_release_secctx(self.secdata, self.seclen as u32) }; + unsafe { bindings::security_release_secctx(&mut self.ctx) }; } }
This brings the Rust SecurityCtx abstraction [1] up to date with the new API where context+len is replaced with an lsm_context [2] struct. Link: https://lore.kernel.org/r/20240915-alice-file-v10-5-88484f7a3dcf@google.com [1] Link: https://lore.kernel.org/r/20241023212158.18718-3-casey@schaufler-ca.com [2] Reported-by: Linux Kernel Functional Testing <lkft@linaro.org> Closes: https://lore.kernel.org/r/CA+G9fYv_Y2tzs+uYhMGtfUK9dSYV2mFr6WyKEzJazDsdk9o5zw@mail.gmail.com Signed-off-by: Alice Ryhl <aliceryhl@google.com> --- rust/helpers/security.c | 8 ++++---- rust/kernel/security.rs | 38 +++++++++++++++++--------------------- 2 files changed, 21 insertions(+), 25 deletions(-) base-commit: c88416ba074a8913cf6d61b789dd834bbca6681c