From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755978AbcBVWGj (ORCPT ); Mon, 22 Feb 2016 17:06:39 -0500 Received: from mx1.redhat.com ([209.132.183.28]:51107 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754469AbcBVWGh (ORCPT ); Mon, 22 Feb 2016 17:06:37 -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> Cc: Laura Abbott , Greg Kroah-Hartman , Arnd Bergmann , "kernel-hardening@lists.openwall.com" , LKML From: Laura Abbott Message-ID: <56CB866A.8070306@redhat.com> Date: Mon, 22 Feb 2016 14:06:34 -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.38]); Mon, 22 Feb 2016 22:06:37 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 02/22/2016 11:27 AM, Kees Cook wrote: > On Fri, Feb 19, 2016 at 3:07 PM, Laura Abbott wrote: >> 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 > > This must be where my confusion stems. :) IIUC, the buddy allocator is > used within the SL*B logic when splitting/joining regions? Can we add > an lkdtm test for this too? > The buddy allocator backs the underlying SL*B logic. Each SL*B allocation is typically less than a page so those allocators manage the smaller allocations. I was thinking about an LKDTM test for the buddy allocator as well. I'll see about adding one. This would be useful for testing debug_pagealloc as well. >> 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. > > If you can point me at the current tree, I'd be happy to run some benchmarks. > mmotm should have the patches http://git.cmpxchg.org/cgit.cgi/linux-mmotm.git/ Turn on CONFIG_PAGE_POISONING and set page_poison=on on the command line. > -Kees > Thanks, Laura