kernelnewbies.kernelnewbies.org archive mirror
 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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).