All of lore.kernel.org
 help / color / mirror / Atom feed
From: ard.biesheuvel@linaro.org (Ard Biesheuvel)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v4] arm64: kernel: implement fast refcount checking
Date: Mon, 31 Jul 2017 22:21:22 +0100	[thread overview]
Message-ID: <CAKv+Gu-TH6qeotkYF+w+KcVJ6pavOYYEkmLKEQTUiDVAcQ1REQ@mail.gmail.com> (raw)
In-Reply-To: <CAGXu5jLZw1aK_wqSiAi3ddxPavOC1i47q4ahnwVnja=gsrLs2w@mail.gmail.com>

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?

> 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.
>

Indeed.

> Nice!
>

Thanks!

WARNING: multiple messages have this Message-ID (diff)
From: Ard Biesheuvel <ard.biesheuvel@linaro.org>
To: Kees Cook <keescook@chromium.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 22:21:22 +0100	[thread overview]
Message-ID: <CAKv+Gu-TH6qeotkYF+w+KcVJ6pavOYYEkmLKEQTUiDVAcQ1REQ@mail.gmail.com> (raw)
In-Reply-To: <CAGXu5jLZw1aK_wqSiAi3ddxPavOC1i47q4ahnwVnja=gsrLs2w@mail.gmail.com>

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?

> 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.
>

Indeed.

> Nice!
>

Thanks!

  reply	other threads:[~2017-07-31 21:21 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
2017-07-31 21:16   ` [kernel-hardening] " Kees Cook
2017-07-31 21:21   ` Ard Biesheuvel [this message]
2017-07-31 21:21     ` 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=CAKv+Gu-TH6qeotkYF+w+KcVJ6pavOYYEkmLKEQTUiDVAcQ1REQ@mail.gmail.com \
    --to=ard.biesheuvel@linaro.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.