linux-kernel - Re: [PATCH 00/14] Pramfs: Persistent and protected ram filesystem

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: <4A3936A0.9050709@nortel.com>
Date:	Wed, 17 Jun 2009 12:32:00 -0600
From:	"Chris Friesen" <cfriesen@...tel.com>
To:	Marco <marco.stornelli@...il.com>
CC:	Linux FS Devel <linux-fsdevel@...r.kernel.org>,
	Linux Embedded <linux-embedded@...r.kernel.org>,
	linux-kernel@...r.kernel.org, Daniel Walker <dwalker@....ucsc.edu>
Subject: Re: [PATCH 00/14] Pramfs: Persistent and protected ram filesystem

Marco wrote:
> This is a second attempt at mainlining Pramfs. The first attempt was
> back in early 2004 by MontaVista. Since then the kernel code has almost
> been completely rewritten. So my first item on the list was porting the
> code on a recent kernel version. After that I added the XIP support.
> 
> Now some FAQs:
> 
> What is the goal of this filesystem?
> 
> Many embedded systems have a block of non-volatile RAM separate from
> normal system memory, i.e. of which the kernel maintains no memory page
> descriptors. For such systems it would be beneficial to mount a
> fast read/write filesystem over this "I/O memory", for storing
> frequently accessed data that must survive system reboots and power
> cycles. An example usage might be system logs under /var/log, or a user
> address book in a cell phone or PDA.

Nice to see something like this submitted to mainline.  We use something
similar to provide persistent storage for crash recovery debug data for
boards which don't have local storage.

In many cases kdump can provide good information, but it's not
sufficient for "flight recorder" type data if the kernel gets rebooted
by a hardware mechanism (watchdog, for instance) that doesn't give a
pre-interrupt.

I'm a bit concerned about your PTE modifications on every write
though...we do things like log every exception and scheduler operation
to persistent memory, and I think the overhead of changing the
protection on every write would be a killer.  Instead, we make extensive
use of checksums at various different levels so that the recovery app
can determine which data is valid.

Also, I'd like to ensure that direct memory access to the memory area
would be available.  There are some things (like the sched/exception
logging mentioned above) where we want to make accesses as fast as possible.

Chris

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