Date:	Sun, 13 Apr 2014 18:43:30 +0200
From:	Richard Weinberger <richard@....at>
To:	Alexander.Kleinsorge@....de
CC:	andi@...stfloor.org,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: new module to check constant memory for corruption

Alex,

please don't crop the recipient list.

Am 13.04.2014 18:26, schrieb Alexander.Kleinsorge@....de:
> Hi Richard,
> 
> I updated my code and check for ftrace (cat /proc/sys/kernel/ftrace_enabled > 0).
> http://tauruz.homeip.net/ramcheck.tgz
> 
> On a 24/7 server ftrace is not a common thing anyway.

I disagree with you.
perf, systemtap and other tools are widely used on "24/7" servers.
As Andi noted, you have to hook all places where kernel code get's modified.

Thanks,
//richard

> Thx, Alex
>  
> 
> Gesendet: Sonntag, 13. April 2014 um 12:26 Uhr
> Von: "Richard Weinberger" <richard.weinberger@...il.com>
> An: Alexander.Kleinsorge@....de
> Cc: "Andi Kleen" <andi@...stfloor.org>, LKML <linux-kernel@...r.kernel.org>
> Betreff: Re: Re: new module to check constant memory for corruption
> On Sun, Apr 13, 2014 at 12:14 PM, <Alexander.Kleinsorge@....de> wrote:
>> Hi Andi,
>>
>> the module considers only the adress range between: kallsyms_lookup_name("_text") .. kallsyms_lookup_name("__end_rodata").
>> this range has a typical size of 10..20 mb (depending on kernel-version and arch).
>> see files: linux-3.*\arch\x86\mm\init_32.c + init_64.c
>> function: void mark_rodata_ro(void)
>> "Write protecting the kernel text: %luk\n"
>> "Write protecting the kernel read-only data: %luk\n"
>> dmesg | grep protecting
>>
>> your question: there are no writes in this write protected adress range (e.g. kernel code).
> 
> And what happens if one enables dynamic ftrace or other kernel
> features which modify kernel code?
> 
>> my idea is to calculate a checksum (xor is fastest) over this range and check later (periodically) if its unchanged.
>> see source code download (5 KB): http://tauruz.homeip.net/ramcheck.tgz
>> the code is working fine and the checksum is (as expected) constant (at least for many hours).
>>
>> regards, Alexander
>>
>>
>> Gesendet: Sonntag, 13. April 2014 um 05:00 Uhr
>> Von: "Andi Kleen" <andi@...stfloor.org>
>> An: Alexander.Kleinsorge@....de
>> Cc: linux-kernel@...r.kernel.org
>> Betreff: Re: new module to check constant memory for corruption
>> Alexander.Kleinsorge@....de writes:
>>
>>> ramcheck kernel module
>>> new module to check constant memory for corruption
>>>
>>> detect corruption of constant kernel memory (text and data) periodically.
>>> runtime costs about 1..2 ms per sec (about 10 mb with 5 mb/ms),
>>> which is distributed over 8 (BLOCKS) time partitions (less than half
>>> ms per sec).
>>> in case of checksum (xor) error, an kernel log is posted.
>>> manual trigger via /proc/ramcheck is possible.
>>> range: kallsyms_lookup_name("_text") .. kallsyms_lookup_name("__end_rodata")
>>
>>
>> Can you explain how this works? How does it handle legal writes?
>>
>> If it just checks its own memory it could be done in user space.
>>
>> -Andi
>>
>> --
>> ak@...ux.intel.com -- Speaking for myself only
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>> the body of a message to majordomo@...r.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html[http://vger.kernel.org/majordomo-info.html]
>> Please read the FAQ at http://www.tux.org/lkml/[http://www.tux.org/lkml/]
> 
> 
> 
> --
> Thanks,
> //richard
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists