Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1337817 > unrolled thread

[PATCHv2] lkdtm: Add READ_AFTER_FREE test

Back to article view | Back to linux.kernel

Contents

  [PATCHv2] lkdtm: Add READ_AFTER_FREE test Laura Abbott <labbott@fedoraproject.org> - 2016-02-19 02:20 +0100
    Re: [PATCHv2] lkdtm: Add READ_AFTER_FREE test Kees Cook <keescook@chromium.org> - 2016-02-19 20:20 +0100
      Re: [PATCHv2] lkdtm: Add READ_AFTER_FREE test Laura Abbott <labbott@redhat.com> - 2016-02-19 23:20 +0100
        Re: [PATCHv2] lkdtm: Add READ_AFTER_FREE test Kees Cook <keescook@chromium.org> - 2016-02-19 23:20 +0100
          Re: [PATCHv2] lkdtm: Add READ_AFTER_FREE test Laura Abbott <labbott@redhat.com> - 2016-02-20 00:10 +0100
            Re: [PATCHv2] lkdtm: Add READ_AFTER_FREE test Kees Cook <keescook@chromium.org> - 2016-02-22 20:30 +0100
              Re: [PATCHv2] lkdtm: Add READ_AFTER_FREE test Laura Abbott <labbott@redhat.com> - 2016-02-22 23:10 +0100

#1337817 — [PATCHv2] lkdtm: Add READ_AFTER_FREE test

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@fedoraproject.org>
---
I split this out from the previous series
(http://article.gmane.org/gmane.linux.kernel.mm/143486) since
that series is going to be going in more incrementally.
Having the test in sooner than later will be helpful I think

v2: Tweaked the output text to be clearer about what's going on.
Switched to using the middle of an allocated block instead of the beginning.
---
 drivers/misc/lkdtm.c | 34 ++++++++++++++++++++++++++++++++++
 1 file changed, 34 insertions(+)

diff --git a/drivers/misc/lkdtm.c b/drivers/misc/lkdtm.c
index 11fdadc..24d0ac7 100644
--- a/drivers/misc/lkdtm.c
+++ b/drivers/misc/lkdtm.c
@@ -92,6 +92,7 @@ enum ctype {
 	CT_UNALIGNED_LOAD_STORE_WRITE,
 	CT_OVERWRITE_ALLOCATION,
 	CT_WRITE_AFTER_FREE,
+	CT_READ_AFTER_FREE,
 	CT_SOFTLOCKUP,
 	CT_HARDLOCKUP,
 	CT_SPINLOCKUP,
@@ -129,6 +130,7 @@ static char* cp_type[] = {
 	"UNALIGNED_LOAD_STORE_WRITE",
 	"OVERWRITE_ALLOCATION",
 	"WRITE_AFTER_FREE",
+	"READ_AFTER_FREE",
 	"SOFTLOCKUP",
 	"HARDLOCKUP",
 	"SPINLOCKUP",
@@ -417,6 +419,38 @@ static void lkdtm_do_action(enum ctype which)
 		memset(data, 0x78, len);
 		break;
 	}
+	case CT_READ_AFTER_FREE: {
+		int **base;
+		int *val, *tmp;
+		size_t len = 1024;
+		/*
+		 * The slub allocator uses the first word to store the free
+		 * pointer in some configurations. Use the middle of the
+		 * allocation to avoid running into the freelist
+		 */
+		size_t offset = (len/sizeof(int *))/2;
+
+		base = kmalloc(len, GFP_KERNEL);
+		if (!base)
+			return;
+
+		val = kmalloc(len, GFP_KERNEL);
+		if (!val)
+			return;
+
+		*val = 0x12345678;
+		pr_info("Value in memory before free: %x\n", *val);
+
+		base[offset] = val;
+		kfree(base);
+
+		tmp = base[offset];
+		pr_info("Attempting to read from freed memory");
+		pr_info("Successfully read value: %x\n", *tmp);
+
+		kfree(val);
+		break;
+	}
 	case CT_SOFTLOCKUP:
 		preempt_disable();
 		for (;;)
-- 
2.5.0

[toc] | [next] | [standalone]

#1338418

On Thu, Feb 18, 2016 at 5:15 PM, Laura Abbott <labbott@fedoraproject.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@fedoraproject.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?)

-Kees

> ---
> I split this out from the previous series
> (http://article.gmane.org/gmane.linux.kernel.mm/143486) since
> that series is going to be going in more incrementally.
> Having the test in sooner than later will be helpful I think
>
> v2: Tweaked the output text to be clearer about what's going on.
> Switched to using the middle of an allocated block instead of the beginning.
> ---
>  drivers/misc/lkdtm.c | 34 ++++++++++++++++++++++++++++++++++
>  1 file changed, 34 insertions(+)
>
> diff --git a/drivers/misc/lkdtm.c b/drivers/misc/lkdtm.c
> index 11fdadc..24d0ac7 100644
> --- a/drivers/misc/lkdtm.c
> +++ b/drivers/misc/lkdtm.c
> @@ -92,6 +92,7 @@ enum ctype {
>         CT_UNALIGNED_LOAD_STORE_WRITE,
>         CT_OVERWRITE_ALLOCATION,
>         CT_WRITE_AFTER_FREE,
> +       CT_READ_AFTER_FREE,
>         CT_SOFTLOCKUP,
>         CT_HARDLOCKUP,
>         CT_SPINLOCKUP,
> @@ -129,6 +130,7 @@ static char* cp_type[] = {
>         "UNALIGNED_LOAD_STORE_WRITE",
>         "OVERWRITE_ALLOCATION",
>         "WRITE_AFTER_FREE",
> +       "READ_AFTER_FREE",
>         "SOFTLOCKUP",
>         "HARDLOCKUP",
>         "SPINLOCKUP",
> @@ -417,6 +419,38 @@ static void lkdtm_do_action(enum ctype which)
>                 memset(data, 0x78, len);
>                 break;
>         }
> +       case CT_READ_AFTER_FREE: {
> +               int **base;
> +               int *val, *tmp;
> +               size_t len = 1024;
> +               /*
> +                * The slub allocator uses the first word to store the free
> +                * pointer in some configurations. Use the middle of the
> +                * allocation to avoid running into the freelist
> +                */
> +               size_t offset = (len/sizeof(int *))/2;
> +
> +               base = kmalloc(len, GFP_KERNEL);
> +               if (!base)
> +                       return;
> +
> +               val = kmalloc(len, GFP_KERNEL);
> +               if (!val)
> +                       return;
> +
> +               *val = 0x12345678;
> +               pr_info("Value in memory before free: %x\n", *val);
> +
> +               base[offset] = val;
> +               kfree(base);
> +
> +               tmp = base[offset];
> +               pr_info("Attempting to read from freed memory");
> +               pr_info("Successfully read value: %x\n", *tmp);
> +
> +               kfree(val);
> +               break;
> +       }
>         case CT_SOFTLOCKUP:
>                 preempt_disable();
>                 for (;;)
> --
> 2.5.0
>



-- 
Kees Cook
Chrome OS & Brillo Security

[toc] | [prev] | [next] | [standalone]

#1338521

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

> -Kees
>
>> ---
>> I split this out from the previous series
>> (http://article.gmane.org/gmane.linux.kernel.mm/143486) since
>> that series is going to be going in more incrementally.
>> Having the test in sooner than later will be helpful I think
>>
>> v2: Tweaked the output text to be clearer about what's going on.
>> Switched to using the middle of an allocated block instead of the beginning.
>> ---
>>   drivers/misc/lkdtm.c | 34 ++++++++++++++++++++++++++++++++++
>>   1 file changed, 34 insertions(+)
>>
>> diff --git a/drivers/misc/lkdtm.c b/drivers/misc/lkdtm.c
>> index 11fdadc..24d0ac7 100644
>> --- a/drivers/misc/lkdtm.c
>> +++ b/drivers/misc/lkdtm.c
>> @@ -92,6 +92,7 @@ enum ctype {
>>          CT_UNALIGNED_LOAD_STORE_WRITE,
>>          CT_OVERWRITE_ALLOCATION,
>>          CT_WRITE_AFTER_FREE,
>> +       CT_READ_AFTER_FREE,
>>          CT_SOFTLOCKUP,
>>          CT_HARDLOCKUP,
>>          CT_SPINLOCKUP,
>> @@ -129,6 +130,7 @@ static char* cp_type[] = {
>>          "UNALIGNED_LOAD_STORE_WRITE",
>>          "OVERWRITE_ALLOCATION",
>>          "WRITE_AFTER_FREE",
>> +       "READ_AFTER_FREE",
>>          "SOFTLOCKUP",
>>          "HARDLOCKUP",
>>          "SPINLOCKUP",
>> @@ -417,6 +419,38 @@ static void lkdtm_do_action(enum ctype which)
>>                  memset(data, 0x78, len);
>>                  break;
>>          }
>> +       case CT_READ_AFTER_FREE: {
>> +               int **base;
>> +               int *val, *tmp;
>> +               size_t len = 1024;
>> +               /*
>> +                * The slub allocator uses the first word to store the free
>> +                * pointer in some configurations. Use the middle of the
>> +                * allocation to avoid running into the freelist
>> +                */
>> +               size_t offset = (len/sizeof(int *))/2;
>> +
>> +               base = kmalloc(len, GFP_KERNEL);
>> +               if (!base)
>> +                       return;
>> +
>> +               val = kmalloc(len, GFP_KERNEL);
>> +               if (!val)
>> +                       return;
>> +
>> +               *val = 0x12345678;
>> +               pr_info("Value in memory before free: %x\n", *val);
>> +
>> +               base[offset] = val;
>> +               kfree(base);
>> +
>> +               tmp = base[offset];
>> +               pr_info("Attempting to read from freed memory");
>> +               pr_info("Successfully read value: %x\n", *tmp);
>> +
>> +               kfree(val);
>> +               break;
>> +       }
>>          case CT_SOFTLOCKUP:
>>                  preempt_disable();
>>                  for (;;)
>> --
>> 2.5.0
>>
>
>
>

[toc] | [prev] | [next] | [standalone]

#1338524

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

-Kees

-- 
Kees Cook
Chrome OS & Brillo Security

[toc] | [prev] | [next] | [standalone]

#1338574

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

[toc] | [prev] | [next] | [standalone]

#1339855

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

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?

> 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.

-Kees

-- 
Kees Cook
Chrome OS & Brillo Security

[toc] | [prev] | [next] | [standalone]

#1339972

On 02/22/2016 11:27 AM, Kees Cook wrote:
> On Fri, Feb 19, 2016 at 3:07 PM, Laura Abbott <labbott@redhat.com> wrote:
>> On 02/19/2016 02:19 PM, Kees Cook wrote:
>>>
>>> On Fri, Feb 19, 2016 at 2:11 PM, Laura Abbott <labbott@redhat.com> wrote:
>>>>
>>>> On 02/19/2016 11:12 AM, Kees Cook wrote:
>>>>>
>>>>>
>>>>> On Thu, Feb 18, 2016 at 5:15 PM, Laura Abbott
>>>>> <labbott@fedoraproject.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@fedoraproject.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
>
> 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

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web