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  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 <>
	Arnd Bergmann <>,,,
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. 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.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

Powered by blists - more mailing lists