rust-for-linux.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Benno Lossin <benno.lossin@proton.me>
To: "Greg KH" <gregkh@linuxfoundation.org>,
	"Miguel Ojeda" <ojeda@kernel.org>,
	"Alex Gaynor" <alex.gaynor@gmail.com>,
	"Wedson Almeida Filho" <wedsonaf@gmail.com>,
	"Boqun Feng" <boqun.feng@gmail.com>,
	"Gary Guo" <gary@garyguo.net>,
	"Björn Roy Baron" <bjorn3_gh@protonmail.com>,
	"Benno Lossin" <benno.lossin@proton.me>,
	"Andreas Hindborg" <a.hindborg@samsung.com>,
	"Alice Ryhl" <aliceryhl@google.com>,
	"Trevor Gross" <tmgross@umich.edu>
Cc: rust-for-linux@vger.kernel.org
Subject: [PATCH 0/3] Untrusted data abstraction
Date: Fri, 13 Sep 2024 11:26:54 +0000	[thread overview]
Message-ID: <20240913112643.542914-1-benno.lossin@proton.me> (raw)

Enable marking certain data as untrusted. For example data coming from
userspace, hardware or any other external data source.

This idea originates from a discussion with Greg at Kangrejos. As far as
I understand the rationale, it is to prevent accidentally reading
untrusted data and using it for *logic* within the kernel. For example
reading the length from the hardware and not validating that it isn't
too big. This is a big source for logic bugs that later turn into
vulnerabilities.

The API introduced in this series is not a silver bullet, users are
still able to access the untrusted value (otherwise how would they be
able to validate it?). But it provides additional guardrails to remind
users that they ought to validate the value before using it. As already
stated, they can access the value directly, but to do that, they need to
explicitly call one of the `untrusted_*` functions signaling to
reviewers that they are reading untrusted data without validation.

There are still some things to iron out on the Rust side:
- allow better handling of `Untrusted<T>`, for example allow comparing
  `Untrusted<[u8]>` for equality (we should do this via a trait
  extending `PartialEq`)
- rebase this on Gary's patch to enable arbitrary self types. This would
  allow me to remove one `untrusted_mut()` call in `inode.rs`. I would
  expose the `cap_len` function even if the underlying data is
  untrusted.
- get more feedback as to what `Untrusted` should make available

In addition to adding the abstraction, I also provide very experimental
RFC patches using the API in tarfs by wedson. They are based on his
vfs-v2 branch [1] and I will not aim to upstream these patches. They should
give you some idea as to how the API is intended to be used.

Open to any suggestions and improvements!

[1]: https://github.com/wedsonaf/linux/tree/vfs-v2

Benno Lossin (3):
  rust: add untrusted data abstraction
  WIP: rust: fs: mark data returned by inodes untrusted
  WIP: rust: tarfs: use untrusted data API

 fs/tarfs/defs.rs        |   1 +
 fs/tarfs/tar.rs         | 143 +++++++++++++++++++++++++++-------------
 rust/kernel/fs/inode.rs |  33 ++++++----
 rust/kernel/types.rs    | 248 ++++++++++++++++++++++++++++++++++++++++++-
 4 files changed, 367 insertions(+), 58 deletions(-)


base-commit: d077242d68a31075ef5f5da041bf8f6fc19aa231
-- 
2.46.0



             reply	other threads:[~2024-09-13 11:27 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-09-13 11:26 Benno Lossin [this message]
2024-09-13 11:26 ` [PATCH 1/3] rust: add untrusted data abstraction Benno Lossin
2024-09-13 13:41   ` Finn Behrens
2024-09-13 13:47     ` Benno Lossin
2024-09-13 15:33   ` Simona Vetter
2024-09-13 16:49     ` Benno Lossin
2024-09-16 15:49       ` Simona Vetter
2024-09-18 15:40         ` Benno Lossin
2024-09-18 17:09           ` Greg KH
2024-09-18 17:33             ` Benno Lossin
2024-09-18 17:39               ` Greg KH
2024-09-20 14:29           ` Simona Vetter
2024-09-20 15:28             ` Benno Lossin
2024-09-21  7:45         ` Benno Lossin
2024-09-23 16:08           ` Simona Vetter
2024-09-23 16:56             ` Benno Lossin
2024-09-24  8:05               ` Simona Vetter
2024-09-13 11:27 ` [RFC PATCH 2/3] WIP: rust: fs: mark data returned by inodes untrusted Benno Lossin
2024-09-13 11:27 ` [RFC PATCH 3/3] WIP: rust: tarfs: use untrusted data API Benno Lossin
2024-09-13 12:10 ` [PATCH 0/3] Untrusted data abstraction Greg KH
2024-09-13 20:43 ` Simona Vetter
2024-09-13 21:31   ` Benno Lossin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20240913112643.542914-1-benno.lossin@proton.me \
    --to=benno.lossin@proton.me \
    --cc=a.hindborg@samsung.com \
    --cc=alex.gaynor@gmail.com \
    --cc=aliceryhl@google.com \
    --cc=bjorn3_gh@protonmail.com \
    --cc=boqun.feng@gmail.com \
    --cc=gary@garyguo.net \
    --cc=gregkh@linuxfoundation.org \
    --cc=ojeda@kernel.org \
    --cc=rust-for-linux@vger.kernel.org \
    --cc=tmgross@umich.edu \
    --cc=wedsonaf@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).