Re: [PATCHv2] lkdtm: Add READ_AFTER_FREE test

From: Kees Cook
Date: Fri Feb 19 2016 - 17:19:23 EST


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?

-Kees

--
Kees Cook
Chrome OS & Brillo Security