[RFC PATCH 0/2] Locking protection for the stats pointer

[John Wood]

Hi,

I'm working in the v3 version of the "fork brute force attack mitigation"
feature (KSPP task). I'm a kernel developer newbie and I think that now
a locking paranoid :)

My post in this mailing list is to get feedback about my locking system.
I'm very afraid about locking. I think that the protection of the stats
structure's internal data about concurrency is correct. But the protection
of a shared pointer among processes is not clear to me.

I divided this post in two patches. The first shows the "brute" LSM code
with the explanation of the main idea behind.

The second patch shows what I think is the correct method to protect the
stats pointer shared among processes.

The code in every patch not represent the changes that will be done in
the version presented to review. I split this changes in this manner to
make easier to comment and clarify my doubts.

Also, this RFC tell about a task_fatal_signal hook that are not shown.
I think that narrow the code will be better, so this part is not sent.

All my questions are presented in the second patch. I would like to know
your comments and opinions. This way I will be able to choose the correct
path about locking avoiding basic errors.

The questions are related to locking not the functionality of the "brute"
LSM. But any constructive comments are always welcome.

The previous versions can be found in:

RFC
https://lore.kernel.org/kernel-hardening/20200910202107.3799376-1-keescook@chromium.org/

v2
https://lore.kernel.org/kernel-hardening/20201025134540.3770-1-john.wood@gmx.com/

Thanks in advance.

John Wood (2):
  security/brute: Brute LSM
  security/brute.c: Protect the stats pointer

 security/brute/brute.c | 381 +++++++++++++++++++++++++++++++++++++++++
 1 file changed, 381 insertions(+)
 create mode 100644 security/brute/brute.c

--
2.25.1