lsm,rust: reword "destroy" -> "release" in SecurityCtx

What happens inside the individual LSMs for a given LSM hook can vary
quite a bit, so it is best to use the terminology "release" instead of
"d

lsm,rust: reword "destroy" -> "release" in SecurityCtx

What happens inside the individual LSMs for a given LSM hook can vary
quite a bit, so it is best to use the terminology "release" instead of
"destroy" or "free".

Suggested-by: Casey Schaufler <[email protected]>
Signed-off-by: Alice Ryhl <[email protected]>
Acked-by: Casey Schaufler <[email protected]>
Reviewed-by: Fiona Behrens <[email protected]>
[PM: subj tweak]
Signed-off-by: Paul Moore <[email protected]>

show more ...

lsm,rust: mark SecurityCtx methods inline

When you build the kernel using the llvm-19.1.4-rust-1.83.0-x86_64
toolchain provided by kernel.org with ARCH=arm64, the following symbols
are generated:

$

lsm,rust: mark SecurityCtx methods inline

When you build the kernel using the llvm-19.1.4-rust-1.83.0-x86_64
toolchain provided by kernel.org with ARCH=arm64, the following symbols
are generated:

$ nm vmlinux | grep ' _R'.*SecurityCtx | rustfilt
... T <kernel::security::SecurityCtx>::from_secid
... T <kernel::security::SecurityCtx as core::ops::drop::Drop>::drop

However, these Rust symbols are trivial wrappers around the functions
security_secid_to_secctx and security_release_secctx respectively. It
doesn't make sense to go through a trivial wrapper for these functions,
so mark them inline. Also mark other trivial methods inline to prevent
similar cases in the future.

After applying this patch, the above command will produce no output.

Reviewed-by: Andreas Hindborg <[email protected]>
Signed-off-by: Alice Ryhl <[email protected]>
Reviewed-by: Fiona Behrens <[email protected]>
[PM: trimmed long description lines, subj tweak]
Signed-off-by: Paul Moore <[email protected]>

show more ...

rust: finish using custom FFI integer types

In the last kernel cycle we migrated most of the `core::ffi` cases in
commit d072acda4862 ("rust: use custom FFI integer types"):

Currently FFI integ

rust: finish using custom FFI integer types

In the last kernel cycle we migrated most of the `core::ffi` cases in
commit d072acda4862 ("rust: use custom FFI integer types"):

Currently FFI integer types are defined in libcore. This commit
creates the `ffi` crate and asks bindgen to use that crate for FFI
integer types instead of `core::ffi`.

This commit is preparatory and no type changes are made in this
commit yet.

Finish now the few remaining/new cases so that we perform the actual
remapping in the next commit as planned.

Acked-by: Jocelyn Falempe <[email protected]> # drm
Link: https://lore.kernel.org/rust-for-linux/CANiq72m_rg42SvZK=bF2f0yEoBLVA33UBhiAsv8THhVu=G2dPA@mail.gmail.com/
Link: https://lore.kernel.org/all/[email protected]/
Signed-off-by: Miguel Ojeda <[email protected]>

show more ...

rust: replace lsm context+len with lsm_context

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

rust: replace lsm context+len with lsm_context

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/[email protected] [1]
Link: https://lore.kernel.org/r/[email protected] [2]
Reported-by: Linux Kernel Functional Testing <[email protected]>
Closes: https://lore.kernel.org/r/CA+G9fYv_Y2tzs+uYhMGtfUK9dSYV2mFr6WyKEzJazDsdk9o5zw@mail.gmail.com
Signed-off-by: Alice Ryhl <[email protected]>
[PM: subj line tweak]
Signed-off-by: Paul Moore <[email protected]>

show more ...

rust: security: add abstraction for secctx

Add an abstraction for viewing the string representation of a security
context.

This is needed by Rust Binder because it has a feature where a process
can

rust: security: add abstraction for secctx

Add an abstraction for viewing the string representation of a security
context.

This is needed by Rust Binder because it has a feature where a process
can view the string representation of the security context for incoming
transactions. The process can use that to authenticate incoming
transactions, and since the feature is provided by the kernel, the
process can trust that the security context is legitimate.

This abstraction makes the following assumptions about the C side:
* When a call to `security_secid_to_secctx` is successful, it returns a
pointer and length. The pointer references a byte string and is valid
for reading for that many bytes.
* The string may be referenced until `security_release_secctx` is
called.
* If CONFIG_SECURITY is set, then the three methods mentioned in
rust/helpers are available without a helper. (That is, they are not a
#define or `static inline`.)

Reviewed-by: Benno Lossin <[email protected]>
Reviewed-by: Martin Rodriguez Reboredo <[email protected]>
Reviewed-by: Trevor Gross <[email protected]>
Reviewed-by: Gary Guo <[email protected]>
Signed-off-by: Alice Ryhl <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Acked-by: Paul Moore <[email protected]>
Reviewed-by: Kees Cook <[email protected]>
Signed-off-by: Christian Brauner <[email protected]>

show more ...