From: Kees Cook <keescook@chromium.org>
To: Alexey Gladkov <gladkov.alexey@gmail.com>
Cc: Jens Axboe <axboe@kernel.dk>,
Kernel Hardening <kernel-hardening@lists.openwall.com>,
Linus Torvalds <torvalds@linux-foundation.org>,
Linux Containers <containers@lists.linux-foundation.org>,
Jann Horn <jannh@google.com>, LKML <linux-kernel@vger.kernel.org>,
Oleg Nesterov <oleg@redhat.com>,
linux-mm@kvack.org, "Eric W . Biederman" <ebiederm@xmission.com>,
Andrew Morton <akpm@linux-foundation.org>,
Alexey Gladkov <legion@kernel.org>,
io-uring@vger.kernel.org
Subject: Re: [PATCH v8 3/8] Use atomic_t for ucounts reference counting
Date: Mon, 15 Mar 2021 15:02:58 -0700 [thread overview]
Message-ID: <202103151426.ED27141@keescook> (raw)
In-Reply-To: <59ee3289194cd97d70085cce701bc494bfcb4fd2.1615372955.git.gladkov.alexey@gmail.com>
On Wed, Mar 10, 2021 at 01:01:28PM +0100, Alexey Gladkov wrote:
> The current implementation of the ucounts reference counter requires the
> use of spin_lock. We're going to use get_ucounts() in more performance
> critical areas like a handling of RLIMIT_SIGPENDING.
This really looks like it should be refcount_t. I read the earlier
thread[1] on this, and it's not clear to me that this is a "normal"
condition. I think there was a bug in that version (This appeared
to *instantly* crash at boot with mnt_init() calling alloc_mnt_ns()
calling inc_ucount()). The current code looks like just a "regular"
reference counter of the allocated struct ucounts. Overflow should be
very unexpected, yes? And operating on a "0" ucounts should be a bug
too, right?
> [...]
> +/* 127: arbitrary random number, small enough to assemble well */
> +#define refcount_zero_or_close_to_overflow(ucounts) \
> + ((unsigned int) atomic_read(&ucounts->count) + 127u <= 127u)
Regardless, this should absolutely not have "refcount" as a prefix. I
realize it's only used here, but that's needlessly confusing with regard
to it being atomic_t not refcount_t.
> +struct ucounts *get_ucounts(struct ucounts *ucounts)
> +{
> + if (ucounts) {
> + if (refcount_zero_or_close_to_overflow(ucounts)) {
> + WARN_ONCE(1, "ucounts: counter has reached its maximum value");
> + return NULL;
> + }
> + atomic_inc(&ucounts->count);
> + }
> + return ucounts;
> +}
I feel like this should just be:
refcount_inc_not_zero(&ucounts->count);
Or, to address Linus's comment in the v3 series, change get_ucounts to
not return NULL first -- I can't see why that can ever happen in v8.
-Kees
[1] https://lore.kernel.org/lkml/116c7669744404364651e3b380db2d82bb23f983.1610722473.git.gladkov.alexey@gmail.com/
--
Kees Cook
_______________________________________________
Containers mailing list
Containers@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/containers
WARNING: multiple messages have this Message-ID (diff)
From: Kees Cook <keescook@chromium.org>
To: Alexey Gladkov <gladkov.alexey@gmail.com>
Cc: LKML <linux-kernel@vger.kernel.org>,
io-uring@vger.kernel.org,
Kernel Hardening <kernel-hardening@lists.openwall.com>,
Linux Containers <containers@lists.linux-foundation.org>,
linux-mm@kvack.org, Alexey Gladkov <legion@kernel.org>,
Andrew Morton <akpm@linux-foundation.org>,
Christian Brauner <christian.brauner@ubuntu.com>,
"Eric W . Biederman" <ebiederm@xmission.com>,
Jann Horn <jannh@google.com>, Jens Axboe <axboe@kernel.dk>,
Linus Torvalds <torvalds@linux-foundation.org>,
Oleg Nesterov <oleg@redhat.com>
Subject: Re: [PATCH v8 3/8] Use atomic_t for ucounts reference counting
Date: Mon, 15 Mar 2021 15:02:58 -0700 [thread overview]
Message-ID: <202103151426.ED27141@keescook> (raw)
In-Reply-To: <59ee3289194cd97d70085cce701bc494bfcb4fd2.1615372955.git.gladkov.alexey@gmail.com>
On Wed, Mar 10, 2021 at 01:01:28PM +0100, Alexey Gladkov wrote:
> The current implementation of the ucounts reference counter requires the
> use of spin_lock. We're going to use get_ucounts() in more performance
> critical areas like a handling of RLIMIT_SIGPENDING.
This really looks like it should be refcount_t. I read the earlier
thread[1] on this, and it's not clear to me that this is a "normal"
condition. I think there was a bug in that version (This appeared
to *instantly* crash at boot with mnt_init() calling alloc_mnt_ns()
calling inc_ucount()). The current code looks like just a "regular"
reference counter of the allocated struct ucounts. Overflow should be
very unexpected, yes? And operating on a "0" ucounts should be a bug
too, right?
> [...]
> +/* 127: arbitrary random number, small enough to assemble well */
> +#define refcount_zero_or_close_to_overflow(ucounts) \
> + ((unsigned int) atomic_read(&ucounts->count) + 127u <= 127u)
Regardless, this should absolutely not have "refcount" as a prefix. I
realize it's only used here, but that's needlessly confusing with regard
to it being atomic_t not refcount_t.
> +struct ucounts *get_ucounts(struct ucounts *ucounts)
> +{
> + if (ucounts) {
> + if (refcount_zero_or_close_to_overflow(ucounts)) {
> + WARN_ONCE(1, "ucounts: counter has reached its maximum value");
> + return NULL;
> + }
> + atomic_inc(&ucounts->count);
> + }
> + return ucounts;
> +}
I feel like this should just be:
refcount_inc_not_zero(&ucounts->count);
Or, to address Linus's comment in the v3 series, change get_ucounts to
not return NULL first -- I can't see why that can ever happen in v8.
-Kees
[1] https://lore.kernel.org/lkml/116c7669744404364651e3b380db2d82bb23f983.1610722473.git.gladkov.alexey@gmail.com/
--
Kees Cook
next prev parent reply other threads:[~2021-03-15 22:03 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-03-10 12:01 [PATCH v8 0/8] Count rlimits in each user namespace Alexey Gladkov
2021-03-10 12:01 ` Alexey Gladkov
2021-03-10 12:01 ` [PATCH v8 1/8] Increase size of ucounts to atomic_long_t Alexey Gladkov
2021-03-10 12:01 ` Alexey Gladkov
2021-03-10 12:01 ` [PATCH v8 2/8] Add a reference to ucounts for each cred Alexey Gladkov
2021-03-10 12:01 ` Alexey Gladkov
2021-03-10 12:01 ` [PATCH v8 3/8] Use atomic_t for ucounts reference counting Alexey Gladkov
2021-03-10 12:01 ` Alexey Gladkov
2021-03-10 21:14 ` Linus Torvalds
2021-03-10 21:14 ` Linus Torvalds
2021-03-15 22:02 ` Kees Cook [this message]
2021-03-15 22:02 ` Kees Cook
2021-03-15 22:19 ` Linus Torvalds
2021-03-15 22:19 ` Linus Torvalds
2021-03-16 18:49 ` Kees Cook
2021-03-16 18:49 ` Kees Cook
2021-03-16 19:26 ` Linus Torvalds
2021-03-16 19:26 ` Linus Torvalds
2021-03-16 19:32 ` Kees Cook
2021-03-16 19:32 ` Kees Cook
2021-03-10 12:01 ` [PATCH v8 4/8] Reimplement RLIMIT_NPROC on top of ucounts Alexey Gladkov
2021-03-10 12:01 ` Alexey Gladkov
2021-03-10 12:01 ` [PATCH v8 5/8] Reimplement RLIMIT_MSGQUEUE " Alexey Gladkov
2021-03-10 12:01 ` Alexey Gladkov
2021-03-10 12:01 ` [PATCH v8 6/8] Reimplement RLIMIT_SIGPENDING " Alexey Gladkov
2021-03-10 12:01 ` Alexey Gladkov
2021-03-10 12:01 ` [PATCH v8 7/8] Reimplement RLIMIT_MEMLOCK " Alexey Gladkov
2021-03-10 12:01 ` Alexey Gladkov
2021-03-10 12:01 ` [PATCH v8 8/8] kselftests: Add test to check for rlimit changes in different user namespaces Alexey Gladkov
2021-03-10 12:01 ` Alexey Gladkov
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=202103151426.ED27141@keescook \
--to=keescook@chromium.org \
--cc=akpm@linux-foundation.org \
--cc=axboe@kernel.dk \
--cc=containers@lists.linux-foundation.org \
--cc=ebiederm@xmission.com \
--cc=gladkov.alexey@gmail.com \
--cc=io-uring@vger.kernel.org \
--cc=jannh@google.com \
--cc=kernel-hardening@lists.openwall.com \
--cc=legion@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=oleg@redhat.com \
--cc=torvalds@linux-foundation.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.