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]

Date:	Wed, 24 Jun 2009 18:41:40 +0100
From:	Jamie Lokier <jamie@...reable.org>
To:	Marco <marco.stornelli@...il.com>
Cc:	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

Marco wrote:
> > Second question: what happens if the system crashing _during_ a write
> > to a file.  Does it mean that file will fail it's checksum when it's
> > read at the next boot?
> > 
> > Maybe files aren't so important.  What about when you write a file,
> > and then rename it over an existing file to replace it.  (E.g. a
> > config file), and the system crashes _during_ the rename?  At the next
> > boot, is it guaranteed to see either the old or the new file, or can
> > the directory be corrupt / fail it's checksum?
> 
> First of all I have to explain better the current policy: the checksum
> works at inode and superblock level and currently there isn't a recovery
> function as the journaling. About the superblock it's easy to use a
> redundant policy to be more robust.

To be honest, superblock robustness is less of a concern.  The real
concern is losing file or directory contents, so it can't be used to
store persistent configuration data, only debugging logs.

> About the inode, at the moment when the checksum doesn't match the
> inode it's marked as bad calling the function make_bad_inode().

Let's see if I understand right.

If it lose power when writing to a file, after boot the file is likely
to be marked bad and so return -EIO instead of any file contents?

If it loses power when doing atomic rename (to replace config files,
for example), it's likely that the whole /pramfs/configs/ directory
will be corrupt, because the rename is writing to the directory inode,
so you lose access to all names in that directory?

That sounds like it can't be used for persistent configuration data.

If a directory is marked as bad, or a file-inode in it is marked bad,
can you even rmdir it to clean up and start again?

Thanks,
-- Jamie
--
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/