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: <2ea1731b0906242344x5c8a6e58t5f82377be3d73411@mail.gmail.com>
Date:	Thu, 25 Jun 2009 08:44:28 +0200
From:	Marco Stornelli <marco.stornelli@...il.com>
To:	Jamie Lokier <jamie@...reable.org>
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

2009/6/24 Jamie Lokier <jamie@...reable.org>:
> 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?

Depends on the checksum. If you lose power before the checksum update
of the inode
you'll have a bad inode and then an -EIO at the next access.

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

It's true from this point of view currently there is a lack for this
and it needs a bit of effort to resolve this problem.
>From this point of view I'd like to point out that I know that there
was some aspects to study in a deeper way, so I'll need
of more then one review :) but since this fs has been abandoned since
2004 and it hadn't ever reviewed, it was important
to do a serious review with the kernel community to understand all the
problems.

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

You can start again always. You can remount the fs with the init
option and then you'll have a new fs.

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/