linux-kernel - [RFC PATCH 3/5] doc: rust: safety standard: add guarantees and type invariants

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <20240717221133.459589-4-benno.lossin@proton.me>
Date: Wed, 17 Jul 2024 22:12:45 +0000
From: Benno Lossin <benno.lossin@...ton.me>
To: Jonathan Corbet <corbet@....net>, Miguel Ojeda <ojeda@...nel.org>, Alex Gaynor <alex.gaynor@...il.com>, Wedson Almeida Filho <wedsonaf@...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>, Andreas Hindborg <a.hindborg@...sung.com>, Alice Ryhl <aliceryhl@...gle.com>
Cc: linux-doc@...r.kernel.org, linux-kernel@...r.kernel.org, rust-for-linux@...r.kernel.org
Subject: [RFC PATCH 3/5] doc: rust: safety standard: add guarantees and type invariants

Add documents about `# Guarantees` and `# Invariants` sections.

Signed-off-by: Benno Lossin <benno.lossin@...ton.me>
---
 .../rust/safety-standard/guarantee.rst        |  9 +++++++++
 Documentation/rust/safety-standard/index.rst  | 16 +++++++++++++++
 .../rust/safety-standard/type-invariants.rst  | 20 +++++++++++++++++++
 3 files changed, 45 insertions(+)
 create mode 100644 Documentation/rust/safety-standard/guarantee.rst
 create mode 100644 Documentation/rust/safety-standard/type-invariants.rst

diff --git a/Documentation/rust/safety-standard/guarantee.rst b/Documentation/rust/safety-standard/guarantee.rst
new file mode 100644
index 000000000000..4d8c811c2bed
--- /dev/null
+++ b/Documentation/rust/safety-standard/guarantee.rst
@@ -0,0 +1,9 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+Guarantees
+==========
+
+Functions and ``struct``, ``enum`` and ``union`` types can list guarantees that ``unsafe`` code can
+rely upon in the ``# Guarantees`` section. Guarantees are listed in an unordered markdown list.
+The wording of guarantees is identical to the wording of requirements.rst. To refer to the return
+value of the function, use ``$ret``.
diff --git a/Documentation/rust/safety-standard/index.rst b/Documentation/rust/safety-standard/index.rst
index bebebda06831..40b17f59709c 100644
--- a/Documentation/rust/safety-standard/index.rst
+++ b/Documentation/rust/safety-standard/index.rst
@@ -221,6 +221,20 @@ similarly to :ref:`unsafe-Blocks`::
     // SAFETY: <justification>
     unsafe impl Foo for Bar {}
 
+Guarantees
+==========
+
+Functions are also allowed to declare certain guarantees that ``unsafe`` code is able to rely upon.
+For example when returning a raw pointer, a common guarantee would be to state that it is valid. See
+guarantee.rst for more info. Importantly, guarantees can also be given by safe functions.
+
+Type Invariants
+---------------
+
+Type invariants are a kind of guarantee. Like their name suggests, they always hold (invariant --
+never changing). They can only be specified on ``struct``, ``enum`` or ``union`` types. See
+type-invariants.rst for more info.
+
 General Rules
 =============
 
@@ -246,6 +260,8 @@ Further Pages
    :maxdepth: 1
 
    examples
+   guarantee
+   type-invariants
 
 .. only::  subproject and html
 
diff --git a/Documentation/rust/safety-standard/type-invariants.rst b/Documentation/rust/safety-standard/type-invariants.rst
new file mode 100644
index 000000000000..dd7e9bda80e5
--- /dev/null
+++ b/Documentation/rust/safety-standard/type-invariants.rst
@@ -0,0 +1,20 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+Type Invariants
+===============
+
+``struct``, ``enum`` and ``union`` types can list type invariants. They are a kind of
+:doc:`guarantee <guarantee>` that ``unsafe`` code can rely upon. They are listed in an unordered
+list in the ``## Invariants`` subsection of the ``# Guarantees`` section. The wording of invariants
+is identical to the wording of requirements.rst. Invariants hold for the entire lifetime of an
+object. During the call of the ``drop`` function these invariants may be violated, since objects
+that are being dropped can never be observed.
+
+Objects with invariants need ``INVARIANT`` comments whenever they are constructed or a field with an
+invariant is modified. The comment is similar to ``SAFETY`` comments and needs to justify that the
+invariant holds. See justifications.rst for how to justify requirements.
+
+Sometimes it is needed to violate an invariant temporarily. For example when inside of a function
+one can temporarily violate the invariant, as long as it is later reestablished and no external code
+can observe the violation. These violations must also be documented using the ``INVARIANT``
+comments.
-- 
2.45.1