linux-kernel - Re: I: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>] [day] [month] [year] [list]

Date:	Wed, 24 Jun 2009 08:30:49 +0200
From:	Marco Stornelli <marco.stornelli@...il.com>
To:	joern@...ybastard.org
Cc:	sam@...nborg.org, tim.bird@...sony.com,
	Arnd Bergmann <arnd@...db.de>, linux-fsdevel@...r.kernel.org,
	linux-embedded@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: I: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.
>

I quite agree, but I'd like to say that it was _not_ my intention to
submit a general-purpose fs comparable with ext2 or ext3.


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

Mmm....Jtag dump makes more sense, ok in the next release I rework the
layout to have an independent endianess layout.

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/