From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1162020AbcBSXHb (ORCPT ); Fri, 19 Feb 2016 18:07:31 -0500 Received: from mx1.redhat.com ([209.132.183.28]:56692 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1161179AbcBSXHa (ORCPT ); Fri, 19 Feb 2016 18:07:30 -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> Cc: Laura Abbott , Greg Kroah-Hartman , Arnd Bergmann , "kernel-hardening@lists.openwall.com" , LKML From: Laura Abbott Message-ID: <56C7A02F.7070902@redhat.com> Date: Fri, 19 Feb 2016 15:07:27 -0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.39]); Fri, 19 Feb 2016 23:07:29 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 02/19/2016 02:19 PM, Kees Cook wrote: > On Fri, Feb 19, 2016 at 2:11 PM, Laura Abbott wrote: >> On 02/19/2016 11:12 AM, Kees Cook wrote: >>> >>> On Thu, Feb 18, 2016 at 5:15 PM, Laura Abbott >>> wrote: >>>> >>>> >>>> In a similar manner to WRITE_AFTER_FREE, add a READ_AFTER_FREE >>>> test to test free poisoning features. Sample output when >>>> no sanitization is present: >>>> >>>> [ 22.414170] lkdtm: Performing direct entry READ_AFTER_FREE >>>> [ 22.415124] lkdtm: Value in memory before free: 12345678 >>>> [ 22.415900] lkdtm: Attempting to read from freed memory >>>> [ 22.416394] lkdtm: Successfully read value: 12345678 >>>> >>>> with sanitization: >>>> >>>> [ 25.874585] lkdtm: Performing direct entry READ_AFTER_FREE >>>> [ 25.875527] lkdtm: Value in memory before free: 12345678 >>>> [ 25.876382] lkdtm: Attempting to read from freed memory >>>> [ 25.876900] general protection fault: 0000 [#1] SMP >>>> >>>> Signed-off-by: Laura Abbott >>> >>> >>> Excellent! Could you mention in the changelog which CONFIG (or runtime >>> values) will change the lkdtm test? (I thought there was a poisoning >>> style that would result in a zero-read instead of a GP?) >>> >> >> There was a zeroing patch in the first draft but given the direction >> things are going, I don't see it going in. I'll mention the debug >> options which will show this though. > > Ah! Okay, I was having trouble following what was happening. What's > the current state of the use-after-free protections you've been > working on? Based on discussion, the SL*B maintainers want to use the existing slab poisoning features instead adding in new hooks. They also don't want the fast path to be affected at all. This means most of the actual work there is improving the performance of slub_debug=P. I sent out patches for some low hanging fruit in SLUB which improved the performance by a good bit. Those have been Acked and are sitting in Andrew's tree. The next performance work involves more in depth tinkering with the SLUB allocator. Apart from just performance, the other work would be poisoning for caches with ctors in SLUB and poisoning in SLOB. I could use some help with benchmarking some actual use cases to see how usable slub_debug=P would be on some use cases. I did sent out patches for the buddy allocator as well. The last version I sent out didn't get much in the way of feedback except for some requests for benchmarks on the zeroing. I was planning on following up on that next week to see if there was any more feedback and beg for Acks. Thanks, Laura > > -Kees > From mboxrd@z Thu Jan 1 00:00:00 1970 Reply-To: kernel-hardening@lists.openwall.com References: <1455844533-24787-1-git-send-email-labbott@fedoraproject.org> <56C79301.5040003@redhat.com> From: Laura Abbott Message-ID: <56C7A02F.7070902@redhat.com> Date: Fri, 19 Feb 2016 15:07:27 -0800 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Subject: [kernel-hardening] Re: [PATCHv2] lkdtm: Add READ_AFTER_FREE test To: Kees Cook Cc: Laura Abbott , Greg Kroah-Hartman , Arnd Bergmann , "kernel-hardening@lists.openwall.com" , LKML List-ID: On 02/19/2016 02:19 PM, Kees Cook wrote: > On Fri, Feb 19, 2016 at 2:11 PM, Laura Abbott wrote: >> On 02/19/2016 11:12 AM, Kees Cook wrote: >>> >>> On Thu, Feb 18, 2016 at 5:15 PM, Laura Abbott >>> wrote: >>>> >>>> >>>> In a similar manner to WRITE_AFTER_FREE, add a READ_AFTER_FREE >>>> test to test free poisoning features. Sample output when >>>> no sanitization is present: >>>> >>>> [ 22.414170] lkdtm: Performing direct entry READ_AFTER_FREE >>>> [ 22.415124] lkdtm: Value in memory before free: 12345678 >>>> [ 22.415900] lkdtm: Attempting to read from freed memory >>>> [ 22.416394] lkdtm: Successfully read value: 12345678 >>>> >>>> with sanitization: >>>> >>>> [ 25.874585] lkdtm: Performing direct entry READ_AFTER_FREE >>>> [ 25.875527] lkdtm: Value in memory before free: 12345678 >>>> [ 25.876382] lkdtm: Attempting to read from freed memory >>>> [ 25.876900] general protection fault: 0000 [#1] SMP >>>> >>>> Signed-off-by: Laura Abbott >>> >>> >>> Excellent! Could you mention in the changelog which CONFIG (or runtime >>> values) will change the lkdtm test? (I thought there was a poisoning >>> style that would result in a zero-read instead of a GP?) >>> >> >> There was a zeroing patch in the first draft but given the direction >> things are going, I don't see it going in. I'll mention the debug >> options which will show this though. > > Ah! Okay, I was having trouble following what was happening. What's > the current state of the use-after-free protections you've been > working on? Based on discussion, the SL*B maintainers want to use the existing slab poisoning features instead adding in new hooks. They also don't want the fast path to be affected at all. This means most of the actual work there is improving the performance of slub_debug=P. I sent out patches for some low hanging fruit in SLUB which improved the performance by a good bit. Those have been Acked and are sitting in Andrew's tree. The next performance work involves more in depth tinkering with the SLUB allocator. Apart from just performance, the other work would be poisoning for caches with ctors in SLUB and poisoning in SLOB. I could use some help with benchmarking some actual use cases to see how usable slub_debug=P would be on some use cases. I did sent out patches for the buddy allocator as well. The last version I sent out didn't get much in the way of feedback except for some requests for benchmarks on the zeroing. I was planning on following up on that next week to see if there was any more feedback and beg for Acks. Thanks, Laura > > -Kees >