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: <CA+jjjYTsKKR2FjXV7f0rLHaN8iLndVd3OkV3m_WdYOM2jsOJAg@mail.gmail.com>
Date:	Sat, 9 Jan 2016 10:45:03 -0800
From:	Joshua Hudson <joshudson@...il.com>
To:	Al Viro <viro@...iv.linux.org.uk>
Cc:	linux-kernel <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] add support for larger files in minix filesystem

> "you need to binary-patch the field at this offset in superblock first"
> are generally considered rude.

That is in fact the only reason why it's safe. I'm not using Minix at all
and don't care what its limit is. I'm using the Minix fs because it's the
only filesystem lightweight enough and fast enough for the embedded
hardware I am developing for (32K total RAM), and I want to be able
to mount the SD card in Linux.

The only alternative is developing a completely new filesystem, and
that's a lot more pain in the behind for everybody.

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.

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