Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1325845

Re: [RFC][PATCH 0/3] Speed up SLUB poisoning + disable checks

Show all headers | View raw

On 01/25/2016 11:03 PM, Joonsoo Kim wrote:
> On Mon, Jan 25, 2016 at 05:15:10PM -0800, Laura Abbott wrote:
>> Hi,
>>
>> Based on the discussion from the series to add slab sanitization
>> (lkml.kernel.org/g/<1450755641-7856-1-git-send-email-laura@labbott.name>)
>> the existing SLAB_POISON mechanism already covers similar behavior.
>> The performance of SLAB_POISON isn't very good. With hackbench -g 20 -l 1000
>> on QEMU with one cpu:
>
> I doesn't follow up that discussion, but, I think that reusing
> SLAB_POISON for slab sanitization needs more changes. I assume that
> completeness and performance is matter for slab sanitization.
>
> 1) SLAB_POISON isn't applied to specific kmem_cache which has
> constructor or SLAB_DESTROY_BY_RCU flag. For debug, it's not necessary
> to be applied, but, for slab sanitization, it is better to apply it to
> all caches.

The grsecurity patches get around this by calling the constructor again
after poisoning. It could be worth investigating doing that as well
although my focus was on the cases without the constructor.
>
> 2) SLAB_POISON makes object size bigger so natural alignment will be
> broken. For example, kmalloc(256) cache's size is 256 in normal
> case but it would be 264 when SLAB_POISON is enabled. This causes
> memory waste.

The grsecurity patches also bump the size up to put the free pointer
outside the object. For sanitization purposes it is cleaner to have
no pointers in the object after free

>
> In fact, I'd prefer not reusing SLAB_POISON. It would make thing
> simpler. But, it's up to Christoph.
>
> Thanks.
>

It basically looks like trying to poison on the fast path at all
will have a negative impact even with the feature is turned off.
Christoph has indicated this is not acceptable so we are forced
to limit it to the slow path only if we want runtime enablement.
If we're limited to the slow path only, we might as well work
with SLAB_POISON to make it faster. We can reevaluate if it turns
out the poisoning isn't fast enough to be useful.

Thanks,
Laura

Back to linux.kernel | Previous | Next — Next in thread | Find similar | Unroll thread

Thread

Re: [RFC][PATCH 0/3] Speed up SLUB poisoning + disable checks Laura Abbott <labbott@redhat.com> - 2016-02-03 19:50 +0100
  Re: [RFC][PATCH 0/3] Speed up SLUB poisoning + disable checks Kees Cook <keescook@chromium.org> - 2016-02-03 22:10 +0100
    Re: [RFC][PATCH 0/3] Speed up SLUB poisoning + disable checks Laura Abbott <labbott@redhat.com> - 2016-02-03 22:40 +0100
      Re: [RFC][PATCH 0/3] Speed up SLUB poisoning + disable checks Christoph Lameter <cl@linux.com> - 2016-02-04 00:10 +0100
        Re: [RFC][PATCH 0/3] Speed up SLUB poisoning + disable checks Laura Abbott <labbott@redhat.com> - 2016-02-04 01:50 +0100
          Re: [RFC][PATCH 0/3] Speed up SLUB poisoning + disable checks Christoph Lameter <cl@linux.com> - 2016-02-04 04:30 +0100

csiph-web