From: Richard Weinberger <richard@nod.at>
To: Alexander.Kleinsorge@gmx.de
Cc: andi@firstfloor.org,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: new module to check constant memory for corruption
Date: Sun, 13 Apr 2014 18:43:30 +0200 [thread overview]
Message-ID: <534ABEB2.7050506@nod.at> (raw)
In-Reply-To: <trinity-99a290b9-30fa-464e-b67b-b8555d48011b-1397406377024@3capp-gmx-bs45>
Alex,
please don't crop the recipient list.
Am 13.04.2014 18:26, schrieb Alexander.Kleinsorge@gmx.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@gmail.com>
> An: Alexander.Kleinsorge@gmx.de
> Cc: "Andi Kleen" <andi@firstfloor.org>, LKML <linux-kernel@vger.kernel.org>
> Betreff: Re: Re: new module to check constant memory for corruption
> On Sun, Apr 13, 2014 at 12:14 PM, <Alexander.Kleinsorge@gmx.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@firstfloor.org>
>> An: Alexander.Kleinsorge@gmx.de
>> Cc: linux-kernel@vger.kernel.org
>> Betreff: Re: new module to check constant memory for corruption
>> Alexander.Kleinsorge@gmx.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@linux.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@vger.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
>
next prev parent reply other threads:[~2014-04-13 16:43 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-04-13 1:33 new module to check constant memory for corruption Alexander.Kleinsorge
2014-04-13 3:00 ` Andi Kleen
2014-04-13 10:14 ` Aw: " Alexander.Kleinsorge
2014-04-13 10:26 ` Richard Weinberger
[not found] ` <trinity-99a290b9-30fa-464e-b67b-b8555d48011b-1397406377024@3capp-gmx-bs45>
2014-04-13 16:43 ` Richard Weinberger [this message]
2014-04-14 14:14 ` Jiri Kosina
2014-04-13 17:20 ` Aw: Re: " Alexander.Kleinsorge
2014-04-13 15:55 ` Andi Kleen
2014-04-13 16:22 ` Aw: " Alexander.Kleinsorge
2014-04-14 8:03 ` Aw: " Alexander.Kleinsorge
2014-04-13 3:08 ` Valdis.Kletnieks
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=534ABEB2.7050506@nod.at \
--to=richard@nod.at \
--cc=Alexander.Kleinsorge@gmx.de \
--cc=andi@firstfloor.org \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.