linux-kernel - Re: [PATCH] add support for larger files in minix 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: <20160109213720.52b2740e@lxorguk.ukuu.org.uk>
Date:	Sat, 9 Jan 2016 21:37:20 +0000
From:	One Thousand Gnomes <gnomes@...rguk.ukuu.org.uk>
To:	Joshua Hudson <joshudson@...il.com>
Cc:	Al Viro <viro@...iv.linux.org.uk>,
	linux-kernel <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] add support for larger files in minix filesystem

> I accessed the minix code at
> http://users.sosdg.org/~qiyong/mxr/source/minix/fs/mfs/read.c
> and they use unsigned for the block variables so the kernel would be
> fine with it; except for super.c truncates the cap at 2GB, so they
> simply won't be able to open large files.

The question is what users in general (notably Minix) do with that. As I
read it both Minix and ELKS will get mightily upset by files over 2GB
long. It would be bad if Linux allowed a user to corrupt their minixfs
images as seen by the normal users of Minix fs.

> Maybe we'd be happier if I limited this to a new superblock magic value;
> and their code won't even mount it.

Yep. That would be sensible. You might also want to pick a fixed
endianness and also decide the bit-endianness of the file system. Minixfs
proper made rather a mess of that.

If your physical media does not suffer from needing to keep blocks on the
same disk cylinder (ie rotating rust) then the V7 file system is even
smaller than the Minix one but also has the 2GB limit.

Alan