All of lore.kernel.org
 help / color / mirror / Atom feed
From: John Wood <john.wood@gmx.com>
To: kernelnewbies@kernelnewbies.org
Cc: John Wood <john.wood@gmx.com>, keescook@chromium.org
Subject: [RFC PATCH 0/2] Locking protection for the stats pointer
Date: Tue,  8 Dec 2020 11:35:55 +0100	[thread overview]
Message-ID: <20201208103557.6471-1-john.wood@gmx.com> (raw)

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


_______________________________________________
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

             reply	other threads:[~2020-12-08 10:37 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-12-08 10:35 John Wood [this message]
2020-12-08 10:35 ` [RFC PATCH 1/2] security/brute: Brute LSM John Wood
2020-12-08 10:35 ` [RFC PATCH 2/2] security/brute.c: Protect the stats pointer John Wood
2020-12-08 14:42   ` Valdis Klētnieks
2020-12-09  9:31     ` John Wood

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=20201208103557.6471-1-john.wood@gmx.com \
    --to=john.wood@gmx.com \
    --cc=keescook@chromium.org \
    --cc=kernelnewbies@kernelnewbies.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.