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: <20090616150750.GF29040@shareable.org>
Date:	Tue, 16 Jun 2009 16:07:50 +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:
> There's the checksum, but the most important feature of this fs is the
> write protection. The page table entries that map the
> backing-store RAM are normally marked read-only. Write operations into
> the filesystem temporarily mark the affected pages as writeable, the
> write operation is carried out with locks held, and then the pte is
> marked read-only again. This feature provides protection against
> filesystem corruption caused by errant writes into the RAM due to
> kernel bugs for instance. I provided a test module for this. When the
> module is loaded tries to do a dirty write in the superblock, at this
> point you should see an error on the write.

Ok.  Random question: does it work with NOMMU? :-)  (I'm biased, my
devices are NOMMU).

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?

> > As you say PRAMFS can work with special SRAMs needing memory
> > protection (and maybe cache coherence?), if you mmap() a file does it
> > need to use the page cache then?  If so, do you have issues with
> > coherency between mmap() and direct read/write?
> 
> See my response above about my concept of protection. However the mmap
> it's a similar approach. I can "mmap" the SRAM and I can write into it
> my data, but I think the possibility to have a fs it's great. We can use
> the device as normal disk, i.e. we can use cp, mv and so on.

I meant when you mmap() a file on the filesystem, like you do when
running an executable, for example.  Does mmap() on a file work or is
it forbidden?  Just curious, I'd guess it's forbidden, and you
wouldn't want _direct_ mappings to the backing SRAM anyway so you can
keep those checksums up to date.

> >> On this point I'd like to hear other embedded guys.
> > 
> > As one, I'd like to say if it can checksum the RAM at boot as well,
> > then I might like to use a small one in ordinary SRAM (at a fixed
> > reserved address) for those occasions when a reboot happens
> > (intentional or not) and I'd like to pass a little data to the next
> > running kernel about why the reboot happened, without touching flash
> > every time.
> > 
> > -- Jamie
> 
> Yeah Jamie, the goal of this fs is exactly that!

Great :-)

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