linux-kernel - Aw: Re: Re: new module to check constant memory for corruption

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <trinity-aed1f545-ee92-43ee-a8a9-85f452aa8aab-1397409611332@3capp-gmx-bs45>
Date:	Sun, 13 Apr 2014 19:20:11 +0200
From:	Alexander.Kleinsorge@....de
To:	linux-kernel@...r.kernel.org
Subject: Aw: Re: Re: new module to check constant memory for corruption

1. KERN_EMERG is now KERN_INFO or ALERT (depending on ftrace_enabled).
2. there is no trigger for real ram errors possible! (only for out of bound writes)
Therefore it is checked periodically and can also be triggered by /proc/ramcheck

Alex

 On Sun, 13 Apr 2014 03:33:10 +0200, Alexander.Kleinsorge [at] gmx said:

> printk(KERN_EMERG MODNAME "error: const kernel memory is broken (%08lx != 0), please reboot!", g_SumLast);

Make a list of all the things that can dynamically modify kernel text while
it's running, starting with the alternatives code, and adding in the various
tracing and debugging tools, and ask yourself if KERN_EMERG is the right
choice here...

Also, that printk is in the wrong place - it only fires if somebody reads
the /proc file, and it *should* trigger as soon as practical after a
problem has been detected.

Bonus points for computing what percent of single, double, triple, and
other error syndromes your xor detects (hint - what is the behavior of a
dead row or column of bits?). 
 

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
View attachment "ramcheck.c" of type "text/plain" (11941 bytes)

Download attachment "ramcheck.tgz" of type "application/octet-stream" (4959 bytes)