Date: Fri, 19 Feb 2016 15:07:27 -0800 From: Laura Abbott <labbott@...hat.com> To: Kees Cook <keescook@...omium.org> Cc: Laura Abbott <labbott@...oraproject.org>, Greg Kroah-Hartman <gregkh@...uxfoundation.org>, Arnd Bergmann <arnd@...db.de>, "kernel-hardening@...ts.openwall.com" <kernel-hardening@...ts.openwall.com>, LKML <linux-kernel@...r.kernel.org> Subject: Re: [PATCHv2] lkdtm: Add READ_AFTER_FREE test On 02/19/2016 02:19 PM, Kees Cook wrote: > On Fri, Feb 19, 2016 at 2:11 PM, Laura Abbott <labbott@...hat.com> wrote: >> On 02/19/2016 11:12 AM, Kees Cook wrote: >>> >>> On Thu, Feb 18, 2016 at 5:15 PM, Laura Abbott <labbott@...oraproject.org> >>> 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 <labbott@...oraproject.org> >>> >>> >>> 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 >
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.