From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751270AbcCABhL (ORCPT ); Mon, 29 Feb 2016 20:37:11 -0500 Received: from mx1.redhat.com ([209.132.183.28]:38607 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750779AbcCABhI (ORCPT ); Mon, 29 Feb 2016 20:37:08 -0500 Subject: Re: [PATCHv2] lkdtm: Add READ_AFTER_FREE test To: Kees Cook References: <1455844533-24787-1-git-send-email-labbott@fedoraproject.org> <56C79301.5040003@redhat.com> <56C7A02F.7070902@redhat.com> <56CB866A.8070306@redhat.com> <56CE072F.7060804@redhat.com> <56CE58BA.3080900@redhat.com> <56CF8B0D.40402@redhat.com> <56D0CF64.10003@redhat.com> Cc: Laura Abbott , Greg Kroah-Hartman , Arnd Bergmann , "kernel-hardening@lists.openwall.com" , LKML From: Laura Abbott Message-ID: <56D4F242.8070508@redhat.com> Date: Mon, 29 Feb 2016 17:37:06 -0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 02/26/2016 02:33 PM, Kees Cook wrote: > On Fri, Feb 26, 2016 at 2:19 PM, Laura Abbott wrote: >> I did a quick hack of zero poisoning for the slab allocator and I >> didn't see any improvement in hackbench performance which is fairly >> sensitive to slab performance. This doesn't surprise me when I >> actually think about it. >> >> Before I sent out my last set of performance optimizations for >> SLUB debug path, I did a profile with ftrace to see if there was >> anything else quick I could do. My profiling showed that the >> poisoning itself was not where most of the allocation time was >> spent. 25-50% of the time was being spent in removing the CPU slab. >> Considering poisoning means that the CPU slab is never really used, >> this can probably be improved. It's worth noting that the >> PAX_MEMORY_SANITIZE implementation still uses the fast path so it >> isn't affected here. (The trade off is a minor penalty on the >> fast path even when poisoning is disabled which isn't acceptable >> to the maintainers currently.) > > Oh right, all of this is still the slow path... > >> Basically, until we've optimized other things I don't think the >> zero poisoning will have a significant effect on performance. >> The next set of optimizations will involve changing some of the >> guts of the SLUB allocator. I have some ideas how to approach this >> but we'll see if they pan out. > > And we can't just have a CONFIG for the fast-path sanitization? Then > it's not in anyone's way, etc? > I proposed that but it was shot down :( The request was to try and make the slow path work so I'm going to do my due diligence there. If it turns out that it still isn't fast enough I'll bring it up again but unless we can say that slow path is still x% slower even after optimization I don't think it will fly. > -Kees > Thanks, Laura