cred,rust: mark Credential 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:

$

cred,rust: mark Credential 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 out-linux/vmlinux | grep ' _R'.*Credential | rustfilt
... T <kernel::cred::Credential>::get_secid
... T <kernel::cred::Credential as
kernel::types::AlwaysRefCounted>::dec_ref
... T <kernel::cred::Credential as
kernel::types::AlwaysRefCounted>::inc_ref

However, these Rust symbols are trivial wrappers around the functions
security_cred_getsecid, get_cred, and put_cred 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: Boqun Feng <[email protected]>
Reviewed-by: Andreas Hindborg <[email protected]>
Reviewed-by: Christian Brauner <[email protected]>
Signed-off-by: Alice Ryhl <[email protected]>
[PM: subject tweak, description line trims]
Signed-off-by: Paul Moore <[email protected]>

show more ...

rust: file: add `Kuid` wrapper

Adds a wrapper around `kuid_t` called `Kuid`. This allows us to define
various operations on kuids such as equality and current_euid. It also
lets us provide conversio

rust: file: add `Kuid` wrapper

Adds a wrapper around `kuid_t` called `Kuid`. This allows us to define
various operations on kuids such as equality and current_euid. It also
lets us provide conversions from kuid into userspace values.

Rust Binder needs these operations because it needs to compare kuids for
equality, and it needs to tell userspace about the pid and uid of
incoming transactions.

To read kuids from a `struct task_struct`, you must currently use
various #defines that perform the appropriate field access under an RCU
read lock. Currently, we do not have a Rust wrapper for rcu_read_lock,
which means that for this patch, there are two ways forward:

1. Inline the methods into Rust code, and use __rcu_read_lock directly
rather than the rcu_read_lock wrapper. This gives up lockdep for
these usages of RCU.

2. Wrap the various #defines in helpers and call the helpers from Rust.

This patch uses the second option. One possible disadvantage of the
second option is the possible introduction of speculation gadgets, but
as discussed in [1], the risk appears to be acceptable.

Of course, once a wrapper for rcu_read_lock is available, it is
preferable to use that over either of the two above approaches.

Link: https://lore.kernel.org/all/202312080947.674CD2DC7@keescook/ [1]
Reviewed-by: Benno Lossin <[email protected]>
Reviewed-by: Martin Rodriguez Reboredo <[email protected]>
Reviewed-by: Trevor Gross <[email protected]>
Signed-off-by: Alice Ryhl <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Christian Brauner <[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 ...

rust: cred: add Rust abstraction for `struct cred`

Add a wrapper around `struct cred` called `Credential`, and provide
functionality to get the `Credential` associated with a `File`.

Rust Binder mu

rust: cred: add Rust abstraction for `struct cred`

Add a wrapper around `struct cred` called `Credential`, and provide
functionality to get the `Credential` associated with a `File`.

Rust Binder must check the credentials of processes when they attempt to
perform various operations, and these checks usually take a
`&Credential` as parameter. The security_binder_set_context_mgr function
would be one example. This patch is necessary to access these security_*
methods from Rust.

This Rust abstraction makes the following assumptions about the C side:
* `struct cred` is refcounted with `get_cred`/`put_cred`.
* It's okay to transfer a `struct cred` across threads, that is, you do
not need to call `put_cred` on the same thread as where you called
`get_cred`.
* The `euid` field of a `struct cred` never changes after
initialization.
* The `f_cred` field of a `struct file` never changes after
initialization.

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

show more ...