linux-kernel - Re: [PATCH 06/14] Pramfs: Include files

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:	Tue, 23 Jun 2009 21:26:49 +0200
From:	Jörn Engel <joern@...ybastard.org>
To:	Marco <marco.stornelli@...il.com>
Cc:	Sam Ravnborg <sam@...nborg.org>, Tim Bird <tim.bird@...sony.com>,
	Chris Simmonds <chris@...t.co.uk>,
	Arnd Bergmann <arnd@...db.de>,
	Linux FS Devel <linux-fsdevel@...r.kernel.org>,
	Linux Embedded <linux-embedded@...r.kernel.org>,
	Linux Kernel <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 06/14] Pramfs: Include files

On Tue, 23 June 2009 19:38:33 +0200, Marco wrote:
> 
> dd? You haven't got any device file to have a dump. I think we're going
> a bit out of scope. I had some doubt to support rootfs in pram and after
> some feedback and the comments of this review I think I'll remove it
> from the next release (to understand some aspects of this fs with the
> kernel community was my main goal for this review). I agree to use the
> native endian. As I said the important thing is that if an user want to
> use it in a 64bit environment then the fs must work well and then it
> must be designed to support even this situation, I think it's obvious.

Glancing at the discussion with Pawel, I see two paths to follow.  One
is to turn pramfs into a full-features all-round general-purpose
filesystem with mkfs, fsck, xattr and any number of additional features.
That way lies doom, as you would compete against ext2+xip and have
little new to offer.

The other path is to make/keep pramfs as simple as possible for
comparatively specialized purposes, like flight recorder data and dump
information.  Main selling point here is the amount of vulnerable code
in the total package.  ext2 + block layer + vfs helpers is relatively
large and many things may go wrong in a panic situation.

So I agree with you that many things expected from general purpose
filesystems simply don't apply to pramfs.  Moving mkfs into the kernel
is a fair tradeoff, when the required code is small.  Endianness is a
different case imo.  dd may not work, but a jtag probe will happily get
you the dump to your development machine.

And even within the same box you can have more than one architecture and
endianness.  http://www.top500.org/system/9707 will show you one such
beast, which happens to have the top bragging rights at the moment.  I
don't want to endorse such strange beasts, but there is no good reason
not to support reading the ppc-written fs from the opteron.  In fact,
there is no reason full stop.

Jörn

-- 
Beware of bugs in the above code; I have only proved it correct, but
not tried it.
-- Donald Knuth
--
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/