Re: [PATCHv2] lkdtm: Add READ_AFTER_FREE test

[Laura Abbott]

On 02/19/2016 02:19 PM, Kees Cook wrote:
> On Fri, Feb 19, 2016 at 2:11 PM, Laura Abbott <labbott@xxxxxxxxxx> wrote:
> > On 02/19/2016 11:12 AM, Kees Cook wrote:
> > > On Thu, Feb 18, 2016 at 5:15 PM, Laura Abbott <labbott@xxxxxxxxxxxxxxxxx>
> > > 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@xxxxxxxxxxxxxxxxx>
> > >
> > >
> > > 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