All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Valdis Klētnieks" <valdis.kletnieks@vt.edu>
To: John Wood <john.wood@gmx.com>
Cc: keescook@chromium.org, kernelnewbies@kernelnewbies.org
Subject: Re: [RFC PATCH 2/2] security/brute.c: Protect the stats pointer
Date: Tue, 08 Dec 2020 09:42:59 -0500	[thread overview]
Message-ID: <4593.1607438579@turing-police> (raw)
In-Reply-To: <20201208103557.6471-3-john.wood@gmx.com>


[-- Attachment #1.1: Type: text/plain, Size: 831 bytes --]

On Tue, 08 Dec 2020 11:35:57 +0100, John Wood said:
> I think the stats pointer present in the task_struct's security blob
> needs to be protected against concurrency for the following reasons.
>
> 1.- The same process forking at the same time in two different CPUs.
> 2.- The same process execve() at the same time in two different CPUs.

OK, I'll bite.  How would these two cases even happen?

(Note that you could conceivably issue the fork()/exeve() on one CPU, run
kernel code for a bit and then get rescheduled onto a different CPU to complete
the syscall, but that's a different cache coherency can-o-worms :)

(Your case 3 of a fork/exec while you traverse is an actual issue.  Note that
you missed one case - where the process evaporates for some reason while you do
the traverse and you're left with a stale pointer...)


[-- Attachment #1.2: Type: application/pgp-signature, Size: 832 bytes --]

[-- Attachment #2: Type: text/plain, Size: 170 bytes --]

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

  reply	other threads:[~2020-12-08 14:44 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-12-08 10:35 [RFC PATCH 0/2] Locking protection for the stats pointer John Wood
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 [this message]
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=4593.1607438579@turing-police \
    --to=valdis.kletnieks@vt.edu \
    --cc=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.