linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
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:36:04 -0700	[thread overview]
Message-ID: <CAGXu5j+M3zVxZRXLw_e1yAS29=eB823+jeidiXX9eUbSR=ZePg@mail.gmail.com> (raw)
In-Reply-To: <CAKv+Gu-TH6qeotkYF+w+KcVJ6pavOYYEkmLKEQTUiDVAcQ1REQ@mail.gmail.com>

On Mon, Jul 31, 2017 at 2:21 PM, Ard Biesheuvel
<ard.biesheuvel@linaro.org> wrote:
> On 31 July 2017 at 22:16, Kees Cook <keescook@chromium.org> wrote:
>> 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?
>
> Yes, but this is essentially what occurs on overflow and sub-to-zero
> as well: the result is always stored before hitting the handler. Isn't
> this the case for x86 as well?

On x86, there's no check for inc/add-from-zero. Double-free would be:

- refcount_dec_and_test() to 0, free
- refcount_inc() to 1,
- refcount_dec_and_test() to 0, free again

Compared to the atomic_t implementation, this risk is unchanged. Also
this case is an "over decrement" which we can't actually protect
against. If the refcount_inc() above happens that means something is
still tracking the object (but it's already been freed, so the
use-after-free has already happened).

x86 refcount_dec() to zero is checked, but this is mainly to find bad
counting in "over decrement" cases, when the code pattern around the
object is using unchecked refcount_dec() instead of
refcount_dec_and_test(). (Frankly, I'd like to see refcount_dec()
entirely removed from the refcount API...)

On overflow, though, no, since we haven't yet reached all the way
around to zero (i.e. it's caught before we can get all the way through
the negative space back through zero to 1 and have a
refcount_dec_and_test() trigger a free).

If I could find a fast way to do the precheck for zero on x86, though,
I'd like to have it, just to be extra-sure.

-Kees

-- 
Kees Cook
Pixel Security

  reply	other threads:[~2017-07-31 21:36 UTC|newest]

Thread overview: 8+ 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 21:16 ` Kees Cook
2017-07-31 21:21   ` Ard Biesheuvel
2017-07-31 21:36     ` Kees Cook [this message]
2017-08-23 14:58 ` Will Deacon
2017-08-23 15:51   ` Ard Biesheuvel
2017-08-23 16:48     ` 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='CAGXu5j+M3zVxZRXLw_e1yAS29=eB823+jeidiXX9eUbSR=ZePg@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 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).