From: Eric Biggers <ebiggers3@gmail.com>
To: "Reshetova, Elena" <elena.reshetova@intel.com>
Cc: Christoph Hellwig <hch@infradead.org>,
"axboe@kernel.dk" <axboe@kernel.dk>,
"james.bottomley@hansenpartnership.com"
<james.bottomley@hansenpartnership.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"linux-block@vger.kernel.org" <linux-block@vger.kernel.org>,
"linux-scsi@vger.kernel.org" <linux-scsi@vger.kernel.org>,
"linux-btrfs@vger.kernel.org" <linux-btrfs@vger.kernel.org>,
"peterz@infradead.org" <peterz@infradead.org>,
"gregkh@linuxfoundation.org" <gregkh@linuxfoundation.org>,
"fujita.tomonori@lab.ntt.co.jp" <fujita.tomonori@lab.ntt.co.jp>,
"mingo@redhat.com" <mingo@redhat.com>, "clm@fb.com" <clm@fb.com>,
"jbacik@fb.com" <jbacik@fb.com>,
"dsterba@suse.com" <dsterba@suse.com>
Subject: Re: [PATCH 0/5] v2: block subsystem refcounter conversions
Date: Thu, 20 Apr 2017 11:33:19 -0700 [thread overview]
Message-ID: <20170420183319.GB103004@gmail.com> (raw)
In-Reply-To: <2236FBA76BA1254E88B949DDB74E612B41C8DA36@IRSMSX102.ger.corp.intel.com>
Hi Elena,
On Thu, Apr 20, 2017 at 04:10:16PM +0000, Reshetova, Elena wrote:
>
> > All the objections from DaveM on the amount of cycles spent on the
> > new refcount_t apply to the block layer fast path operations as well.
>
> Ok, could you please indicate the correct way to measure the impact for the block layer?
> We can do the measurements.
>
> Best Regards,
> Elena.
>
> >
> > Please don't send any more conversions until those have been resolved.
Like I suggested months ago, how about doing an efficient implementation of
refcount_t which doesn't use the bloated cmpxchg loop? Then there would be no
need for endless performance arguments. In fact, in PaX there are already
example implementations for several architectures. It's unfortunate that
they're still being ignored for some reason.
At the very least, what is there now could probably be made about twice as fast
by removing the checks that don't actually help mitigate refcount overflow bugs,
specifically all the checks in refcount_dec(), and the part of refcount_inc()
where it doesn't allow incrementing a 0 refcount. Hint: if a refcount is 0, the
object has already been freed, so the attacker will have had the opportunity to
allocate it with contents they control already.
Of course, having extra checks behind a debug option is fine. But they should
not be part of the base feature; the base feature should just be mitigation of
reference count *overflows*. It would be nice to do more, of course; but when
the extra stuff prevents people from using refcount_t for performance reasons,
it defeats the point of the feature in the first place.
I strongly encourage anyone who has been involved in refcount_t to experiment
with removing a reference count decrement somewhere in their kernel, then trying
to exploit it to gain code execution. If you don't know what you're trying to
protect against, you will not know which defences work and which don't.
- Eric
next prev parent reply other threads:[~2017-04-20 18:33 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-04-20 11:27 [PATCH 0/5] v2: block subsystem refcounter conversions Elena Reshetova
2017-04-20 11:27 ` [PATCH 1/5] block: convert bio.__bi_cnt from atomic_t to refcount_t Elena Reshetova
2017-04-20 11:27 ` [PATCH 2/5] block: convert blk_queue_tag.refcnt " Elena Reshetova
2017-04-20 11:27 ` [PATCH 3/5] block: convert blkcg_gq.refcnt " Elena Reshetova
2017-04-20 11:27 ` [PATCH 4/5] block: convert io_context.active_ref " Elena Reshetova
2017-04-20 11:27 ` [PATCH 5/5] block: convert bsg_device.ref_count " Elena Reshetova
2017-04-20 13:56 ` [PATCH 0/5] v2: block subsystem refcounter conversions Christoph Hellwig
2017-04-20 16:10 ` Reshetova, Elena
2017-04-20 18:33 ` Eric Biggers [this message]
2017-04-21 10:55 ` Reshetova, Elena
2017-04-21 14:03 ` Jens Axboe
2017-04-21 15:22 ` Peter Zijlstra
2017-04-21 16:29 ` Jens Axboe
2017-04-21 17:11 ` Kees Cook
2017-04-21 19:55 ` Eric Biggers
2017-04-21 20:22 ` Kees Cook
2017-04-21 21:27 ` James Bottomley
2017-04-21 21:30 ` Kees Cook
2017-04-21 22:01 ` James Bottomley
2017-04-21 10:56 ` Christoph Hellwig
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=20170420183319.GB103004@gmail.com \
--to=ebiggers3@gmail.com \
--cc=axboe@kernel.dk \
--cc=clm@fb.com \
--cc=dsterba@suse.com \
--cc=elena.reshetova@intel.com \
--cc=fujita.tomonori@lab.ntt.co.jp \
--cc=gregkh@linuxfoundation.org \
--cc=hch@infradead.org \
--cc=james.bottomley@hansenpartnership.com \
--cc=jbacik@fb.com \
--cc=linux-block@vger.kernel.org \
--cc=linux-btrfs@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-scsi@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=peterz@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).