From: Aleksandr Nogikh <[email protected]>
Describe fail_lsm_hooks fault injection capability.
Signed-off-by: Aleksandr Nogikh <[email protected]>
---
v2:
- Added this commit.
---
Documentation/fault-injection/fault-injection.rst | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/Documentation/fault-injection/fault-injection.rst b/Documentation/fault-injection/fault-injection.rst
index 31ecfe44e5b4..48705adfbc18 100644
--- a/Documentation/fault-injection/fault-injection.rst
+++ b/Documentation/fault-injection/fault-injection.rst
@@ -48,6 +48,12 @@ Available fault injection capabilities
status code is NVME_SC_INVALID_OPCODE with no retry. The status code and
retry flag can be set via the debugfs.
+- fail_lsm_hooks
+
+ injects failures into LSM hooks. When a fault is injected, actual hooks
+ are not executed and a code from /sys/kernel/debug/fail_lsm_hooks/retval
+ is returned (the default value is -EACCES).
+
Configure fault-injection capabilities behavior
-----------------------------------------------
--
2.29.0.rc1.297.gfa9743e501-goog
2020年10月26日(月) 21:52 Aleksandr Nogikh <[email protected]>:
>
> From: Aleksandr Nogikh <[email protected]>
>
> Describe fail_lsm_hooks fault injection capability.
>
> Signed-off-by: Aleksandr Nogikh <[email protected]>
> ---
> v2:
> - Added this commit.
> ---
> Documentation/fault-injection/fault-injection.rst | 6 ++++++
> 1 file changed, 6 insertions(+)
>
> diff --git a/Documentation/fault-injection/fault-injection.rst b/Documentation/fault-injection/fault-injection.rst
> index 31ecfe44e5b4..48705adfbc18 100644
> --- a/Documentation/fault-injection/fault-injection.rst
> +++ b/Documentation/fault-injection/fault-injection.rst
> @@ -48,6 +48,12 @@ Available fault injection capabilities
> status code is NVME_SC_INVALID_OPCODE with no retry. The status code and
> retry flag can be set via the debugfs.
>
> +- fail_lsm_hooks
> +
> + injects failures into LSM hooks. When a fault is injected, actual hooks
> + are not executed and a code from /sys/kernel/debug/fail_lsm_hooks/retval
> + is returned (the default value is -EACCES).
In addition to this global one, what do you think about per-hook fault
injection,
i.e. /sys/kernel/debug/fail_lsm_hooks/<FUNC>/retval ?
In this case, we need a fault_attr for each hook. (Maybe, we can use the same
technique that is used to define security_hook_heads).
On Tue, Oct 27, 2020 at 6:31 PM Akinobu Mita <[email protected]> wrote:
>
[...]
> In addition to this global one, what do you think about per-hook fault
> injection,
> i.e. /sys/kernel/debug/fail_lsm_hooks/<FUNC>/retval ?
I was thinking about this, but decided to begin with a simple version
that could definitely be useful in practice (for syzbot/syzkaller it is just
necessary to have a fault injection capability that will be triggered via
fail-nth). If per-hook fault injection can also be useful to someone, I
can try to add it as well.
> In this case, we need a fault_attr for each hook. (Maybe, we can use the same
> technique that is used to define security_hook_heads).
Yes, that technique should help to implement the feature in a very concise
way. Thanks for the suggestion.
On Tue, Oct 27, 2020 at 6:34 PM Aleksandr Nogikh <[email protected]> wrote:
> [...]
> > In addition to this global one, what do you think about per-hook fault
> > injection,
> > i.e. /sys/kernel/debug/fail_lsm_hooks/<FUNC>/retval ?
>
> I was thinking about this, but decided to begin with a simple version
> that could definitely be useful in practice (for syzbot/syzkaller it is just
> necessary to have a fault injection capability that will be triggered via
> fail-nth). If per-hook fault injection can also be useful to someone, I
> can try to add it as well.
Yes, before we add it, it would be useful to have a clear use case
(otherwise we can add an unused thing, or implement it in a way that
slightly misses the use case).
Note that fail-nth allows to fail a single concrete site for testing,
though it's not super convenient for this as one would need to figure
out the right N first. But as a one-off test it should do.
> > In this case, we need a fault_attr for each hook. (Maybe, we can use the same
> > technique that is used to define security_hook_heads).
>
> Yes, that technique should help to implement the feature in a very concise
> way. Thanks for the suggestion.