From: keescook@chromium.org (Kees Cook)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v4] arm64: kernel: implement fast refcount checking
Date: Mon, 31 Jul 2017 14:16:21 -0700 [thread overview]
Message-ID: <CAGXu5jLZw1aK_wqSiAi3ddxPavOC1i47q4ahnwVnja=gsrLs2w@mail.gmail.com> (raw)
In-Reply-To: <20170731192251.12491-1-ard.biesheuvel@linaro.org>
On Mon, Jul 31, 2017 at 12:22 PM, Ard Biesheuvel
<ard.biesheuvel@linaro.org> wrote:
> v4: Implement add-from-zero checking using a conditional compare rather than
> a conditional branch, which I omitted from v3 due to the 10% performance
> hit: this will result in the new refcount to be written back to memory
> before invoking the handler, which is more in line with the other checks,
> and is apparently much easier on the branch predictor, given that there
> is no performance hit whatsoever.
So refcount_inc() and refcount_add(n, ...) will write 1 and n
respectively, then hit the handler to saturate? That seems entirely
fine to me: checking inc-from-zero is just a protection against a
possible double-free condition. It's still technically a race, but a
narrow race on a rare condition is better than being able to always
win it.
Nice!
-Kees
--
Kees Cook
Pixel Security
WARNING: multiple messages have this Message-ID (diff)
From: Kees Cook <keescook@chromium.org>
To: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: "linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>,
"kernel-hardening@lists.openwall.com"
<kernel-hardening@lists.openwall.com>,
Will Deacon <will.deacon@arm.com>,
Mark Rutland <mark.rutland@arm.com>,
Laura Abbott <labbott@fedoraproject.org>,
Li Kun <hw.likun@huawei.com>
Subject: [kernel-hardening] Re: [PATCH v4] arm64: kernel: implement fast refcount checking
Date: Mon, 31 Jul 2017 14:16:21 -0700 [thread overview]
Message-ID: <CAGXu5jLZw1aK_wqSiAi3ddxPavOC1i47q4ahnwVnja=gsrLs2w@mail.gmail.com> (raw)
In-Reply-To: <20170731192251.12491-1-ard.biesheuvel@linaro.org>
On Mon, Jul 31, 2017 at 12:22 PM, Ard Biesheuvel
<ard.biesheuvel@linaro.org> wrote:
> v4: Implement add-from-zero checking using a conditional compare rather than
> a conditional branch, which I omitted from v3 due to the 10% performance
> hit: this will result in the new refcount to be written back to memory
> before invoking the handler, which is more in line with the other checks,
> and is apparently much easier on the branch predictor, given that there
> is no performance hit whatsoever.
So refcount_inc() and refcount_add(n, ...) will write 1 and n
respectively, then hit the handler to saturate? That seems entirely
fine to me: checking inc-from-zero is just a protection against a
possible double-free condition. It's still technically a race, but a
narrow race on a rare condition is better than being able to always
win it.
Nice!
-Kees
--
Kees Cook
Pixel Security
next prev parent reply other threads:[~2017-07-31 21:16 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-07-31 19:22 [PATCH v4] arm64: kernel: implement fast refcount checking Ard Biesheuvel
2017-07-31 19:22 ` [kernel-hardening] " Ard Biesheuvel
2017-07-31 21:16 ` Kees Cook [this message]
2017-07-31 21:16 ` [kernel-hardening] " Kees Cook
2017-07-31 21:21 ` Ard Biesheuvel
2017-07-31 21:21 ` [kernel-hardening] " Ard Biesheuvel
2017-07-31 21:36 ` Kees Cook
2017-07-31 21:36 ` [kernel-hardening] " Kees Cook
2017-08-23 14:58 ` Will Deacon
2017-08-23 14:58 ` [kernel-hardening] " Will Deacon
2017-08-23 15:51 ` Ard Biesheuvel
2017-08-23 15:51 ` [kernel-hardening] " Ard Biesheuvel
2017-08-23 16:48 ` Kees Cook
2017-08-23 16:48 ` [kernel-hardening] " Kees Cook
2017-09-03 10:16 Ard Biesheuvel
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='CAGXu5jLZw1aK_wqSiAi3ddxPavOC1i47q4ahnwVnja=gsrLs2w@mail.gmail.com' \
--to=keescook@chromium.org \
--cc=linux-arm-kernel@lists.infradead.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.