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: <4A4119DB.4030203@gmail.com>
Date:	Tue, 23 Jun 2009 20:07:23 +0200
From:	Marco <marco.stornelli@...il.com>
To:	Pavel Machek <pavel@....cz>
CC:	Tim Bird <tim.bird@...sony.com>,
	Jamie Lokier <jamie@...reable.org>,
	Linux Embedded <linux-embedded@...r.kernel.org>,
	Linux Kernel <linux-kernel@...r.kernel.org>,
	Linux FS Devel <linux-fsdevel@...r.kernel.org>,
	Daniel Walker <dwalker@....ucsc.edu>
Subject: Re: [PATCH 00/14] Pramfs: Persistent and protected ram filesystem

Pavel Machek wrote:
> On Mon 2009-06-22 14:50:01, Tim Bird wrote:
>> Pavel Machek wrote:
>>>> block of fast non-volatile RAM that need to access data on it using a
>>>> standard filesytem interface."
>>> Turns a block of fast RAM into 13MB/sec disk. Hmm. I believe you are
>>> better with ext2.
>> Not if you want the RAM-based filesystem to persist over a kernel
>> invocation.
> 
> Yes, you'll need to code Persistent, RAM-based _block_device_. 
> 									Pavel

First of all I have to say that I'd like to update the site and make it
clearer but at the moment it's not possible because I'm not the admin
and I've already asked to the sourceforge support to have this possibility.

About the comments: sincerely I don't understand the comments. We have
*already* a fs that takes care to remap a piace of ram (ram, sram,
nvram, etc.), takes care of caching problems, takes care of write
protection, takes care to be "persistent", can use xip and it's my
intention to add in the next future other features like acl, xattr and
so on.

You are talked about journaling. This schema works well for a disk, but
what about a piece of ram? What about a crazy kernel that write in that
area for a bug? Do you remember for example the e1000e bug? It's not
casual that this fs use an hw protection schema. I mean, this fs is not
only a "yet another fs", but a fs born with a specific target. So I
think modifying a ramdisk to have these behaviors isn't a little
modification.

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